[Apcupsd-users] Rebooting master apcupsd causes "ONLINE REPLACEBATT" status on network slave

Discussion:

Daniel Born

2017-05-08 01:03:26 UTC

After installing version 3.14.14 apcupsd on all my linux computers, I
noticed this situation: if I reboot the network master apcupsd, while it
is offline, the network slave shows "ONLINE REPLACEBATT" status instead
of "ONLINE SLAVE". I just replaced the UPS' battery a little over a
month ago and while the master is running, everything is fine.

I figured this was a possible bug with version 3.14.14 so I reinstalled
the previous stable version 3.14.12 on the x86 computer (master) and
version 3.14.10 on the raspberry pi (slave) and I still see the same
behavior. I don't recall seeing that in the past.

Anybody have an explanation for this? or can suggest something to
investigate?

Thanks,
Daniel

Ted Mittelstaedt

2017-05-08 06:10:57 UTC

Permalink

I see that too but when the network master apcupsd comes back online the
slaves

go back to normal.

Why do you think this is a bug? Essentially when the master is offline
you are

telling the slaves to connect to an unused IP address.

If rebooting the master caused the slaves to all initiate a shutdown -
THAT I would call

a bug!

Ted

Post by Daniel Born
After installing version 3.14.14 apcupsd on all my linux computers, I
noticed this situation: if I reboot the network master apcupsd, while it
is offline, the network slave shows "ONLINE REPLACEBATT" status instead
of "ONLINE SLAVE". I just replaced the UPS' battery a little over a
month ago and while the master is running, everything is fine.
I figured this was a possible bug with version 3.14.14 so I reinstalled
the previous stable version 3.14.12 on the x86 computer (master) and
version 3.14.10 on the raspberry pi (slave) and I still see the same
behavior. I don't recall seeing that in the past.
Anybody have an explanation for this? or can suggest something to
investigate?
Thanks,
Daniel
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Apcupsd-users mailing list
https://lists.sourceforge.net/lists/listinfo/apcupsd-users

Daniel Born

2017-05-08 09:32:23 UTC

Permalink

Well, I would expect it to go to something like OFFLINE. Reporting the battery as needing replacement, doesn't seem like intended behavior.

It's not causing any harm, it just seemed odd to me.

Thanks,
Daniel

Post by Ted Mittelstaedt
I see that too but when the network master apcupsd comes back online the
slaves
go back to normal.
Why do you think this is a bug? Essentially when the master is offline
you are
telling the slaves to connect to an unused IP address.
If rebooting the master caused the slaves to all initiate a shutdown -
THAT I would call
a bug!
Ted

Post by Daniel Born
After installing version 3.14.14 apcupsd on all my linux computers, I
noticed this situation: if I reboot the network master apcupsd, while

Post by Daniel Born
is offline, the network slave shows "ONLINE REPLACEBATT" status

instead

Post by Daniel Born
of "ONLINE SLAVE". I just replaced the UPS' battery a little over a
month ago and while the master is running, everything is fine.
I figured this was a possible bug with version 3.14.14 so I

reinstalled

Post by Daniel Born
the previous stable version 3.14.12 on the x86 computer (master) and
version 3.14.10 on the raspberry pi (slave) and I still see the same
behavior. I don't recall seeing that in the past.
Anybody have an explanation for this? or can suggest something to
investigate?
Thanks,
Daniel

------------------------------------------------------------------------------

Post by Daniel Born
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Apcupsd-users mailing list
https://lists.sourceforge.net/lists/listinfo/apcupsd-users

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Apcupsd-users mailing list
https://lists.sourceforge.net/lists/listinfo/apcupsd-users

--
Sent from my Samsung Galaxy S4

Allan Dyer

2017-05-08 09:53:54 UTC

Permalink

I think this is a bug because the message, "ONLINE REPLACEBATT" is
inaccurate and misleading: The battery does not need replacing.

In detail, the spurious message occurs immediately after communications
is re-established, from my logs:

2017-04-19 13:00:24 +0800 Communications with UPS lost.
2017-04-19 13:01:28 +0800 Communications with UPS restored.
2017-04-19 13:01:28 +0800 UPS battery must be replaced.

So, it is not producing the message because the communications is lost,
perhaps it knows it has re-established communications, but has not yet
received the battery status?

Regards

Allan

Ted Mittelstaedt

2017-05-09 22:30:37 UTC

Permalink

If a UPS is queried too quickly after it produces the results of a
prior query, it will often respond with zeros.

I don't know if you can call this a bug or just an artifact of the slow
CPU that is in a typical UPS, and I don't know if all of them do it.

But I do know when I was writing my client for apcupsd that I had to
add delays into the status query because apcupsd also seems to suffer
the same restriction and does not buffer or otherwise throttle
successive queries that come in too fast.

Most likely what is happening here is the slave apcupsd is polling to
see if the master is alive again, then finally sees that it -is- alive
again then doesn't give it enough time before sending another status
query. So you get 2 status queries back-to-back, and apcupsd sends
them to the ups too quickly then gets zeros. It then corrects later on
after settling into it's regular poll cycle.

Ted

Post by Allan Dyer
I think this is a bug because the message, "ONLINE REPLACEBATT" is
inaccurate and misleading: The battery does not need replacing.
In detail, the spurious message occurs immediately after communications
2017-04-19 13:00:24 +0800 Communications with UPS lost.
2017-04-19 13:01:28 +0800 Communications with UPS restored.
2017-04-19 13:01:28 +0800 UPS battery must be replaced.
So, it is not producing the message because the communications is lost,
perhaps it knows it has re-established communications, but has not yet
received the battery status?
Regards
Allan

Allan Dyer

2017-05-10 03:44:09 UTC

Permalink

Thanks for the likely explanation, Ted.

Would it be possible to add a delay to the status query when the master
comes alive?
I would characterise this as a bug, because it is giving an incorrect
warning, "REPLACEBATT" to the administrator. However, it is an annoyance
bug, not a critical bug. The worst case is that someone wastes money
replacing batteries.

Allan

Post by Ted Mittelstaedt
If a UPS is queried too quickly after it produces the results of a
prior query, it will often respond with zeros.
I don't know if you can call this a bug or just an artifact of the slow
CPU that is in a typical UPS, and I don't know if all of them do it.
But I do know when I was writing my client for apcupsd that I had to
add delays into the status query because apcupsd also seems to suffer
the same restriction and does not buffer or otherwise throttle
successive queries that come in too fast.
Most likely what is happening here is the slave apcupsd is polling to
see if the master is alive again, then finally sees that it -is- alive
again then doesn't give it enough time before sending another status
query. So you get 2 status queries back-to-back, and apcupsd sends
them to the ups too quickly then gets zeros. It then corrects later on
after settling into it's regular poll cycle.
Ted

Ted Mittelstaedt

2017-05-13 21:57:18 UTC

Permalink

Allan, if you are using a linux desktop what are you using on the slaves
that is displaying this status? Is it a desktop icon or something? Are
you opening a command window and running apcaccess in it?

Ted

Post by Allan Dyer
Thanks for the likely explanation, Ted.
Would it be possible to add a delay to the status query when the master
comes alive?
I would characterise this as a bug, because it is giving an incorrect
warning, "REPLACEBATT" to the administrator. However, it is an annoyance
bug, not a critical bug. The worst case is that someone wastes money
replacing batteries.
Allan

Allan Dyer

2017-05-15 04:14:41 UTC

Permalink

Ted, those machines are servers, no GUI. The slave emails me when
there's an event. I can also see the alert in the log file
/var/log/apcupsd.events

If I run apcaccess from the command line on the slave, the status line
currently says:

STATUS : ONLINE SLAVE

I *think* I've seen

STATUS : ONLINE SLAVE REPLACEBATT

shortly after a master reboot, about the time the email alert is sent,
but I didn't make a positive record, so I might be conflating with the
email content.

Allan

Post by Ted Mittelstaedt
Allan, if you are using a linux desktop what are you using on the slaves
that is displaying this status? Is it a desktop icon or something? Are
you opening a command window and running apcaccess in it?
Ted

Ted Mittelstaedt

2017-05-19 04:33:33 UTC

Permalink

OK then it sounds like your using the apcaccess program in an email
script of some kind

that periodically runs apcaccess every minute or so?

Ted

Post by Allan Dyer
Ted, those machines are servers, no GUI. The slave emails me when
there's an event. I can also see the alert in the log file
/var/log/apcupsd.events
If I run apcaccess from the command line on the slave, the status line
STATUS : ONLINE SLAVE
I *think* I've seen
STATUS : ONLINE SLAVE REPLACEBATT
shortly after a master reboot, about the time the email alert is sent,
but I didn't make a positive record, so I might be conflating with the
email content.
Allan

Allan Dyer

2017-05-21 06:34:24 UTC

Permalink

I'm just using the standard changeme script, which gets called by
apccontrol when apcupsd detects that the battery needs changing:

#!/bin/sh
#
# This shell script if placed in /etc/apcupsd
# will be called by /etc/apcupsd/apccontrol when apcupsd
# detects that the battery should be replaced.
# We send an email message to root to notify him.
#

HOSTNAME=`hostname`
MSG="$HOSTNAME UPS $1 battery needs changing NOW."
#
(
echo "Subject: $MSG"
echo " "
echo "$MSG"
echo " "
/sbin/apcaccess status
) | $APCUPSD_MAIL -s "$MSG" $SYSADMIN
exit 0

---

Allan

Post by Ted Mittelstaedt
OK then it sounds like your using the apcaccess program in an email
script of some kind
that periodically runs apcaccess every minute or so?
Ted

Ted Mittelstaedt

2017-05-21 18:28:17 UTC

Permalink

OK well a hacky way of fixing this would be for you to put a pause in
that script of about 20 seconds right before calling apcaccess.

You will still get the battery change emails but inside the email will
be a status printout of the UPS showing that the battery does not need
changing. (unless of course, the battery really does need changing in
which case the emails will have a status output showing that)

Are you running the changeme script on the machine with the UPS sense
cable plugged into it?

Ted

Post by Allan Dyer
I'm just using the standard changeme script, which gets called by
#!/bin/sh
#
# This shell script if placed in /etc/apcupsd
# will be called by /etc/apcupsd/apccontrol when apcupsd
# detects that the battery should be replaced.
# We send an email message to root to notify him.
#
HOSTNAME=`hostname`
MSG="$HOSTNAME UPS $1 battery needs changing NOW."
#
(
echo "Subject: $MSG"
echo " "
echo "$MSG"
echo " "
/sbin/apcaccess status
) | $APCUPSD_MAIL -s "$MSG" $SYSADMIN
exit 0
---
Allan

Post by Ted Mittelstaedt
OK then it sounds like your using the apcaccess program in an email
script of some kind
that periodically runs apcaccess every minute or so?
Ted

a***@vampire.com.hk

2017-05-22 02:03:17 UTC

Permalink

Thanks, I'll try that, or I'll remove the changeme script on the slave.
Yes, I've got the changeme script on the machine with the sense cable.
It's obvious when you put it like that: there's no reason to have the
changeme script on the slave.

I have to admit that I wasn't paying attention to how it was working, I
installed apcupsd years ago, it "just worked" once I configured it, and
it was only recently that the spurious messages started.

I suggest adding a note to the documentation pointing out the changeme
script is unnecessary on slaves.

Allan

Post by Ted Mittelstaedt
OK well a hacky way of fixing this would be for you to put a pause in
that script of about 20 seconds right before calling apcaccess.
You will still get the battery change emails but inside the email will
be a status printout of the UPS showing that the battery does not need
changing. (unless of course, the battery really does need changing in
which case the emails will have a status output showing that)
Are you running the changeme script on the machine with the UPS sense
cable plugged into it?
Ted

Post by Ted Mittelstaedt
OK then it sounds like your using the apcaccess program in an email
script of some kind
that periodically runs apcaccess every minute or so?
Ted

Ted Mittelstaedt

2017-05-22 07:16:36 UTC

Permalink

I was thinking you might have been running it on the slaves.

Ted

Post by a***@vampire.com.hk
Thanks, I'll try that, or I'll remove the changeme script on the slave.
Yes, I've got the changeme script on the machine with the sense cable.
It's obvious when you put it like that: there's no reason to have the
changeme script on the slave.
I have to admit that I wasn't paying attention to how it was working, I
installed apcupsd years ago, it "just worked" once I configured it, and
it was only recently that the spurious messages started.
I suggest adding a note to the documentation pointing out the changeme
script is unnecessary on slaves.
Allan

Post by Ted Mittelstaedt
OK then it sounds like your using the apcaccess program in an email
script of some kind
that periodically runs apcaccess every minute or so?
Ted

Allan Dyer

2017-05-22 08:21:20 UTC

Permalink

I had it on both master and slave. As I said, I wasn't paying attention
to the detail when I installed, and it's not an issue to get two warning
messages when there is a problem. But that set me up for the spurious
messages when the behaviour changed.

Allan

Post by Ted Mittelstaedt
I was thinking you might have been running it on the slaves.
Ted

Post by Ted Mittelstaedt
OK then it sounds like your using the apcaccess program in an email
script of some kind
that periodically runs apcaccess every minute or so?
Ted