Rebooting master apcupsd causes "ONLINE REPLACEBATT" status on network slave

classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

Rebooting master apcupsd causes "ONLINE REPLACEBATT" status on network slave

Daniel Born-2
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/apcupsd-users
Reply | Threaded
Open this post in threaded view
|

Re: Rebooting master apcupsd causes "ONLINE REPLACEBATT" status on network slave

Ted Mittelstaedt-5
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


On 5/7/2017 6:03 PM, Daniel Born wrote:

> 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
> [hidden email]
> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/apcupsd-users
Reply | Threaded
Open this post in threaded view
|

Re: Rebooting master apcupsd causes "ONLINE REPLACEBATT" status on network slave

Daniel Born-2
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

On May 8, 2017 2:10:57 AM EDT, Ted Mittelstaedt <[hidden email]> wrote:
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


On 5/7/2017 6:03 PM, Daniel Born wrote:
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
[hidden email]
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/apcupsd-users

--
Sent from my Samsung Galaxy S4
------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/apcupsd-users
Reply | Threaded
Open this post in threaded view
|

Re: Rebooting master apcupsd causes "ONLINE REPLACEBATT" status on network slave

apcupsd-4
In reply to this post by Ted Mittelstaedt-5
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


On Monday, May 08, 2017 02:10 PM, Ted Mittelstaedt wrote:

> 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
>
>
> On 5/7/2017 6:03 PM, Daniel Born wrote:
>> 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
>> [hidden email]
>> 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
> [hidden email]
> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/apcupsd-users
Reply | Threaded
Open this post in threaded view
|

Re: Rebooting master apcupsd causes "ONLINE REPLACEBATT" status on network slave

Ted Mittelstaedt-5
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

On 5/8/2017 2:53 AM, Allan Dyer wrote:

> 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
>
>
> On Monday, May 08, 2017 02:10 PM, Ted Mittelstaedt wrote:
>> 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
>>
>>
>> On 5/7/2017 6:03 PM, Daniel Born wrote:
>>> 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
>>> [hidden email]
>>> 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
>> [hidden email]
>> 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
> [hidden email]
> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/apcupsd-users
Reply | Threaded
Open this post in threaded view
|

Re: Rebooting master apcupsd causes "ONLINE REPLACEBATT" status on network slave

apcupsd-4
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

On Wednesday, May 10, 2017 06:30 AM, Ted Mittelstaedt wrote:

> 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
>
> On 5/8/2017 2:53 AM, Allan Dyer wrote:
>> 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
>>
>>
>> On Monday, May 08, 2017 02:10 PM, Ted Mittelstaedt wrote:
>>> 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
>>>
>>>
>>> On 5/7/2017 6:03 PM, Daniel Born wrote:
>>>> 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
>>>> [hidden email]
>>>> 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
>>> [hidden email]
>>> 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
>> [hidden email]
>> 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
> [hidden email]
> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/apcupsd-users
Reply | Threaded
Open this post in threaded view
|

Re: Rebooting master apcupsd causes "ONLINE REPLACEBATT" status on network slave

Ted Mittelstaedt-5

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

On 5/9/2017 8:44 PM, Allan Dyer wrote:

> 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
>
> On Wednesday, May 10, 2017 06:30 AM, Ted Mittelstaedt wrote:
>> 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
>>
>> On 5/8/2017 2:53 AM, Allan Dyer wrote:
>>> 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
>>>
>>>
>>> On Monday, May 08, 2017 02:10 PM, Ted Mittelstaedt wrote:
>>>> 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
>>>>
>>>>
>>>> On 5/7/2017 6:03 PM, Daniel Born wrote:
>>>>> 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
>>>>> [hidden email]
>>>>> 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
>>>> [hidden email]
>>>> 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
>>> [hidden email]
>>> 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
>> [hidden email]
>> 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
> [hidden email]
> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/apcupsd-users
Reply | Threaded
Open this post in threaded view
|

Re: Rebooting master apcupsd causes "ONLINE REPLACEBATT" status on network slave

apcupsd-4
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


On 14/5/17 5:57 am, Ted Mittelstaedt wrote:

> 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
>
> On 5/9/2017 8:44 PM, Allan Dyer wrote:
>> 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
>>
>> On Wednesday, May 10, 2017 06:30 AM, Ted Mittelstaedt wrote:
>>> 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
>>>
>>> On 5/8/2017 2:53 AM, Allan Dyer wrote:
>>>> 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
>>>>
>>>>
>>>> On Monday, May 08, 2017 02:10 PM, Ted Mittelstaedt wrote:
>>>>> 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
>>>>>
>>>>>
>>>>> On 5/7/2017 6:03 PM, Daniel Born wrote:
>>>>>> 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
>>>>>> [hidden email]
>>>>>> 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
>>>>> [hidden email]
>>>>> 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
>>>> [hidden email]
>>>> 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
>>> [hidden email]
>>> 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
>> [hidden email]
>> 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
> [hidden email]
> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/apcupsd-users
Reply | Threaded
Open this post in threaded view
|

Re: Rebooting master apcupsd causes "ONLINE REPLACEBATT" status on network slave

Ted Mittelstaedt-5
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

On 5/14/2017 9:14 PM, Allan Dyer wrote:

> 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
>
>
> On 14/5/17 5:57 am, Ted Mittelstaedt wrote:
>> 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
>>
>> On 5/9/2017 8:44 PM, Allan Dyer wrote:
>>> 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
>>>
>>> On Wednesday, May 10, 2017 06:30 AM, Ted Mittelstaedt wrote:
>>>> 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
>>>>
>>>> On 5/8/2017 2:53 AM, Allan Dyer wrote:
>>>>> 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
>>>>>
>>>>>
>>>>> On Monday, May 08, 2017 02:10 PM, Ted Mittelstaedt wrote:
>>>>>> 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
>>>>>>
>>>>>>
>>>>>> On 5/7/2017 6:03 PM, Daniel Born wrote:
>>>>>>> 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
>>>>>>> [hidden email]
>>>>>>> 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
>>>>>> [hidden email]
>>>>>> 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
>>>>> [hidden email]
>>>>> 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
>>>> [hidden email]
>>>> 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
>>> [hidden email]
>>> 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
>> [hidden email]
>> 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
> [hidden email]
> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/apcupsd-users
Reply | Threaded
Open this post in threaded view
|

Re: Rebooting master apcupsd causes "ONLINE REPLACEBATT" status on network slave

apcupsd-4
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


On Friday, May 19, 2017 12:33 PM, Ted Mittelstaedt wrote:

> 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
>
> On 5/14/2017 9:14 PM, Allan Dyer wrote:
>> 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
>>
>>
>> On 14/5/17 5:57 am, Ted Mittelstaedt wrote:
>>> 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
>>>
>>> On 5/9/2017 8:44 PM, Allan Dyer wrote:
>>>> 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
>>>>
>>>> On Wednesday, May 10, 2017 06:30 AM, Ted Mittelstaedt wrote:
>>>>> 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
>>>>>
>>>>> On 5/8/2017 2:53 AM, Allan Dyer wrote:
>>>>>> 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
>>>>>>
>>>>>>
>>>>>> On Monday, May 08, 2017 02:10 PM, Ted Mittelstaedt wrote:
>>>>>>> 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
>>>>>>>
>>>>>>>
>>>>>>> On 5/7/2017 6:03 PM, Daniel Born wrote:
>>>>>>>> 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
>>>>>>>> [hidden email]
>>>>>>>> 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
>>>>>>> [hidden email]
>>>>>>> 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
>>>>>> [hidden email]
>>>>>> 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
>>>>> [hidden email]
>>>>> 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
>>>> [hidden email]
>>>> 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
>>> [hidden email]
>>> 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
>> [hidden email]
>> 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
> [hidden email]
> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/apcupsd-users
Reply | Threaded
Open this post in threaded view
|

Re: Rebooting master apcupsd causes "ONLINE REPLACEBATT" status on network slave

Ted Mittelstaedt-5

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

On 5/20/2017 11:34 PM, Allan Dyer wrote:

> 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
>
>
> On Friday, May 19, 2017 12:33 PM, Ted Mittelstaedt wrote:
>> 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
>>
>> On 5/14/2017 9:14 PM, Allan Dyer wrote:
>>> 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
>>>
>>>
>>> On 14/5/17 5:57 am, Ted Mittelstaedt wrote:
>>>> 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
>>>>
>>>> On 5/9/2017 8:44 PM, Allan Dyer wrote:
>>>>> 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
>>>>>
>>>>> On Wednesday, May 10, 2017 06:30 AM, Ted Mittelstaedt wrote:
>>>>>> 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
>>>>>>
>>>>>> On 5/8/2017 2:53 AM, Allan Dyer wrote:
>>>>>>> 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
>>>>>>>
>>>>>>>
>>>>>>> On Monday, May 08, 2017 02:10 PM, Ted Mittelstaedt wrote:
>>>>>>>> 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
>>>>>>>>
>>>>>>>>
>>>>>>>> On 5/7/2017 6:03 PM, Daniel Born wrote:
>>>>>>>>> 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
>>>>>>>>> [hidden email]
>>>>>>>>> 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
>>>>>>>> [hidden email]
>>>>>>>> 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
>>>>>>> [hidden email]
>>>>>>> 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
>>>>>> [hidden email]
>>>>>> 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
>>>>> [hidden email]
>>>>> 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
>>>> [hidden email]
>>>> 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
>>> [hidden email]
>>> 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
>> [hidden email]
>> 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
> [hidden email]
> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/apcupsd-users
Reply | Threaded
Open this post in threaded view
|

Re: Rebooting master apcupsd causes "ONLINE REPLACEBATT" status on network slave

apcupsd-4
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


On 22/5/17 2:28 am, Ted Mittelstaedt wrote:

> 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
>
> On 5/20/2017 11:34 PM, Allan Dyer wrote:
>> 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
>>
>>
>> On Friday, May 19, 2017 12:33 PM, Ted Mittelstaedt wrote:
>>> 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
>>>
>>> On 5/14/2017 9:14 PM, Allan Dyer wrote:
>>>> 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
>>>>
>>>>
>>>> On 14/5/17 5:57 am, Ted Mittelstaedt wrote:
>>>>> 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
>>>>>
>>>>> On 5/9/2017 8:44 PM, Allan Dyer wrote:
>>>>>> 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
>>>>>>
>>>>>> On Wednesday, May 10, 2017 06:30 AM, Ted Mittelstaedt wrote:
>>>>>>> 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
>>>>>>>
>>>>>>> On 5/8/2017 2:53 AM, Allan Dyer wrote:
>>>>>>>> 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
>>>>>>>>
>>>>>>>>
>>>>>>>> On Monday, May 08, 2017 02:10 PM, Ted Mittelstaedt wrote:
>>>>>>>>> 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
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 5/7/2017 6:03 PM, Daniel Born wrote:
>>>>>>>>>> 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
>>>>>>>>>> [hidden email]
>>>>>>>>>> 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
>>>>>>>>> [hidden email]
>>>>>>>>> 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
>>>>>>>> [hidden email]
>>>>>>>> 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
>>>>>>> [hidden email]
>>>>>>> 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
>>>>>> [hidden email]
>>>>>> 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
>>>>> [hidden email]
>>>>> 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
>>>> [hidden email]
>>>> 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
>>> [hidden email]
>>> 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
>> [hidden email]
>> 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
> [hidden email]
> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/apcupsd-users
Reply | Threaded
Open this post in threaded view
|

Re: Rebooting master apcupsd causes "ONLINE REPLACEBATT" status on network slave

Ted Mittelstaedt-5
I was thinking you might have been running it on the slaves.

Ted

On 5/21/2017 7:03 PM, [hidden email] wrote:

> 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
>
>
> On 22/5/17 2:28 am, Ted Mittelstaedt wrote:
>> 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
>>
>> On 5/20/2017 11:34 PM, Allan Dyer wrote:
>>> 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
>>>
>>>
>>> On Friday, May 19, 2017 12:33 PM, Ted Mittelstaedt wrote:
>>>> 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
>>>>
>>>> On 5/14/2017 9:14 PM, Allan Dyer wrote:
>>>>> 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
>>>>>
>>>>>
>>>>> On 14/5/17 5:57 am, Ted Mittelstaedt wrote:
>>>>>> 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
>>>>>>
>>>>>> On 5/9/2017 8:44 PM, Allan Dyer wrote:
>>>>>>> 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
>>>>>>>
>>>>>>> On Wednesday, May 10, 2017 06:30 AM, Ted Mittelstaedt wrote:
>>>>>>>> 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
>>>>>>>>
>>>>>>>> On 5/8/2017 2:53 AM, Allan Dyer wrote:
>>>>>>>>> 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
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Monday, May 08, 2017 02:10 PM, Ted Mittelstaedt wrote:
>>>>>>>>>> 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
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 5/7/2017 6:03 PM, Daniel Born wrote:
>>>>>>>>>>> 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
>>>>>>>>>>> [hidden email]
>>>>>>>>>>> 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
>>>>>>>>>> [hidden email]
>>>>>>>>>> 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
>>>>>>>>> [hidden email]
>>>>>>>>> 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
>>>>>>>> [hidden email]
>>>>>>>> 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
>>>>>>> [hidden email]
>>>>>>> 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
>>>>>> [hidden email]
>>>>>> 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
>>>>> [hidden email]
>>>>> 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
>>>> [hidden email]
>>>> 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
>>> [hidden email]
>>> 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
>> [hidden email]
>> 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
> [hidden email]
> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/apcupsd-users
Reply | Threaded
Open this post in threaded view
|

Re: Rebooting master apcupsd causes "ONLINE REPLACEBATT" status on network slave

apcupsd-4
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


On 22/5/17 3:16 pm, Ted Mittelstaedt wrote:

> I was thinking you might have been running it on the slaves.
>
> Ted
>
> On 5/21/2017 7:03 PM, [hidden email] wrote:
>> 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
>>
>>
>> On 22/5/17 2:28 am, Ted Mittelstaedt wrote:
>>> 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
>>>
>>> On 5/20/2017 11:34 PM, Allan Dyer wrote:
>>>> 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
>>>>
>>>>
>>>> On Friday, May 19, 2017 12:33 PM, Ted Mittelstaedt wrote:
>>>>> 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
>>>>>
>>>>> On 5/14/2017 9:14 PM, Allan Dyer wrote:
>>>>>> 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
>>>>>>
>>>>>>
>>>>>> On 14/5/17 5:57 am, Ted Mittelstaedt wrote:
>>>>>>> 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
>>>>>>>
>>>>>>> On 5/9/2017 8:44 PM, Allan Dyer wrote:
>>>>>>>> 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
>>>>>>>>
>>>>>>>> On Wednesday, May 10, 2017 06:30 AM, Ted Mittelstaedt wrote:
>>>>>>>>> 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
>>>>>>>>>
>>>>>>>>> On 5/8/2017 2:53 AM, Allan Dyer wrote:
>>>>>>>>>> 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
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Monday, May 08, 2017 02:10 PM, Ted Mittelstaedt wrote:
>>>>>>>>>>> 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
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On 5/7/2017 6:03 PM, Daniel Born wrote:
>>>>>>>>>>>> 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
>>>>>>>>>>>> [hidden email]
>>>>>>>>>>>> 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
>>>>>>>>>>> [hidden email]
>>>>>>>>>>> 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
>>>>>>>>>> [hidden email]
>>>>>>>>>> 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
>>>>>>>>> [hidden email]
>>>>>>>>> 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
>>>>>>>> [hidden email]
>>>>>>>> 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
>>>>>>> [hidden email]
>>>>>>> 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
>>>>>> [hidden email]
>>>>>> 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
>>>>> [hidden email]
>>>>> 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
>>>> [hidden email]
>>>> 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
>>> [hidden email]
>>> 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
>> [hidden email]
>> 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
> [hidden email]
> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/apcupsd-users