Re: [Nut-upsuser] battery not installed, but battery still 100% and NUT 2.7.2-4 does not catch this and report a error

[Jon Bendtsen]

On 04/04/17 15.19, Arnaud Quette wrote:




[cuuut]


there is a Github issue: https://github.com/networkupstools/nut/issues/415
+ a branch with the implementation:
https://github.com/networkupstools/nut/tree/upsmon_alarm

For now:
- upsmon can react on the ALARM notify type, as with other events, and
WALL+SYSLOG+EXEC...
- I've also fixed the CGI to expose the ALARM flag, which was not done.

A possible improvement would be to send the content of ups.alarm, but that
requires more thinking and time.
And the current implementation already points at this data.

@Jon: would you be able to test this branch and ack? (including the "covers (or
not) my needs...)


yeah, I can do that, but I'd prefer to wait a few days and test with a machine 
that does nothing else and with NUT software that my main servers does not rely on.


I've just ordered a new Eaton 5SC 1500i as a replacement because it is listed as 
very well supported. Once it gets here I'll get the broken UPS free and I'll 
install the NUT software on a test machine.




JonB


___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] battery not installed, but battery still 100% and NUT 2.7.2-4 does not catch this and report a error

[Arnaud Quette]

2017-04-04 14:18 GMT+02:00 Jon Bendtsen :

> On 04/04/17 14.10, Roger Price wrote:
>
>> On Tue, 4 Apr 2017, Arnaud Quette wrote:
>>
>>
> [cut]
>
> Hi Arnaud, It seems to me that, looking out into the future, there are
>> three
>> things upsmon needs:
>>
>> 1. A fall-through  of "UNKNOWN" so that all status changes,
>> no
>> matter how wierd, can be caught.  Such a catch-all  would
>> also have
>> caught the "ALARM" from the old battery.
>>
>> 2. A UPS specific option in the NOTIFYFLAG and NOTIFYMSG declarations as
>> already
>> provided by the AT declaration in upssched.conf.  This would make it
>> possible to
>> have messages and action specific to a UPS, in a multi-UPS configuration.
>>
>> I would like to be able to specify
>>
>>NOTIFYMSG myups@localhost  ONBATT "%s: local UPS on battery"
>>NOTIFYMSG bigups@serverONBATT "%s: Server room alert: UPS on
>> battery"
>>
>>NOTIFYFLAG myups@localhost ONBATT SYSLOG+EXEC+WALL
>>NOTIFYFLAG heartbeat@localhost ONBATT SYSLOG+EXEC
>>
>> 3. A  "ALARM" as you propose.
>>
>
> good ideas
>

there is a Github issue: https://github.com/networkupstools/nut/issues/415
+ a branch with the implementation:
https://github.com/networkupstools/nut/tree/upsmon_alarm

For now:
- upsmon can react on the ALARM notify type, as with other events, and
WALL+SYSLOG+EXEC...
- I've also fixed the CGI to expose the ALARM flag, which was not done.

A possible improvement would be to send the content of ups.alarm, but that
requires more thinking and time.
And the current implementation already points at this data.

@Jon: would you be able to test this branch and ack? (including the "covers
(or not) my needs...)

thanks and cheers,
Arno
-- 
Eaton Data Center Automation Solutions - Opensource Leader -
http://42ity.org
NUT (Network UPS Tools) Project Leader - http://www.networkupstools.org
Debian Developer - http://www.debian.org
Free Software Developer - http://arnaud.quette.fr
___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] battery not installed, but battery still 100% and NUT 2.7.2-4 does not catch this and report a error

[Jon Bendtsen]

On 04/04/17 14.10, Roger Price wrote:

On Tue, 4 Apr 2017, Arnaud Quette wrote:



[cut]


Hi Arnaud, It seems to me that, looking out into the future, there are three
things upsmon needs:

1. A fall-through  of "UNKNOWN" so that all status changes, no
matter how wierd, can be caught.  Such a catch-all  would also have
caught the "ALARM" from the old battery.

2. A UPS specific option in the NOTIFYFLAG and NOTIFYMSG declarations as already
provided by the AT declaration in upssched.conf.  This would make it possible to
have messages and action specific to a UPS, in a multi-UPS configuration.

I would like to be able to specify

   NOTIFYMSG myups@localhost  ONBATT "%s: local UPS on battery"
   NOTIFYMSG bigups@serverONBATT "%s: Server room alert: UPS on battery"

   NOTIFYFLAG myups@localhost ONBATT SYSLOG+EXEC+WALL
   NOTIFYFLAG heartbeat@localhost ONBATT SYSLOG+EXEC

3. A  "ALARM" as you propose.


good ideas



JonB


___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] battery not installed, but battery still 100% and NUT 2.7.2-4 does not catch this and report a error

[Roger Price]

On Tue, 4 Apr 2017, Arnaud Quette wrote:


Hi Jon, Stuart and the list

2017-04-04 1:09 GMT+02:00 Stuart Gathman :
  Which NOTIFYCMD is run when there is an ALARM?
  Have you specified that in your upsmon.conf?

  And that is the question of the hour.  How do you specify that?  Note
  that this is not the REPLBATT status we are talking about.

It's true that upsmon doesn't deal with ALARM, and that's definitely something 
missing.

What about adding a  "ALARM" to upsmon (and its .conf), and have 
it processing like other notifications?
That would mean to you can have WALL / SYSLOG notifications, along with EXEC 
reaction if NOTIFYCMD is set.


Hi Arnaud, It seems to me that, looking out into the future, there are 
three things upsmon needs:


1. A fall-through  of "UNKNOWN" so that all status changes, 
no matter how wierd, can be caught.  Such a catch-all  would 
also have caught the "ALARM" from the old battery.


2. A UPS specific option in the NOTIFYFLAG and NOTIFYMSG declarations as 
already provided by the AT declaration in upssched.conf.  This would make 
it possible to have messages and action specific to a UPS, in a multi-UPS 
configuration.


I would like to be able to specify

   NOTIFYMSG myups@localhost  ONBATT "%s: local UPS on battery"
   NOTIFYMSG bigups@serverONBATT "%s: Server room alert: UPS on battery"

   NOTIFYFLAG myups@localhost ONBATT SYSLOG+EXEC+WALL
   NOTIFYFLAG heartbeat@localhost ONBATT SYSLOG+EXEC

3. A  "ALARM" as you propose.

Best Regards, Roger___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Is a timer a file?

[Arnaud Quette]

Hi Roger,

2017-03-28 15:07 GMT+02:00 Roger Price :

> Hi Arnaud,
>
> On Wed, 22 Mar 2017, Arnaud Quette wrote:
>
>   The technique is very general and is to send SIGUSR1/SIGUSR2 to the
>> upsd daemon.  SIGUSR1 and SIGUSR2 are events just like ONBATT and ONLINE.
>>   The patch runs successfully on my opensuse 13.2 box, and solves my
>> problem. In upssched.conf I now have declarations such as
>>
>>  AT SIGUSR1 * CANCEL-TIMER shutdown-timer
>>
>>   Will my patches be included in NUT?
>>
>> I've quickly checked your 2 patches.  The solution seems to me not broad
>> enough for injecting upstream. This works nice for a single device / UPS
>> setup, but would not make it when there are more devices, as I get it.
>>
>
> True, I use SIGUSR1 and SIGUSR2 which do not allow a payload such as a UPS
> unit name.  That would require SIGQUEUE, which accepts integers and
> pointers to other values (such as UPS unit names), but a Bash script can
> only send integers with SIGQUEUE.  Sending pointers to UPS unit names would
> require a new C program.  This would be a good programming exercise, but
> no-one has asked for such a facility in NUT.
>
> I suspect that only a small percentage of NUT users use upssched timers.
>
> At first sight, I would more see something injecting into the PIPEFN fifo,
>> i.e. acting the same way upsmon would when calling upssched with the
>> upsname and the triggering event.
>> I think that this can be solved more easily with tools like socat or nc,
>> sending the command directly to the pipe. For example, to cancel the timer
>> "shutdown-timer" from the upssched-cmd script, you would:
>>
>>echo "CANCEL shutdown-timer" | socat -
>> UNIX-CLIENT:/var/run/nut/upssched.pipe
>>
>
> What a hack! :-) Sure, it is possible to do clever things with such tools,
> but I wanted something that used the .conf files to express the
> configuration.
>
> I also considered using a dummy UPS with a .dev script written and erased
> as needed by a Bash script.
>
> Please tell me back if such solution would make it for you.
>>
>
> For the moment I will stick with my SIGUSR patches.
>
> I also realize that the distributed sample configuration and scripts do
>> not fully match the doc. I'll make another round of update for this, still
>> on the same branch.
>>
>
> I would warmly welcome your help to complete the documentation, both with
>> part of your patches that make sense,
>>
>
> I think the user documentation would benefit from an explanation that
> there are two possible approaches to NUT configuration: Simple/optimistic,
> without timers, and pessimistic with timers.  And then a complete, fully
> worked example of the NUT setup for the simplest usage based on OB and LB
> (no timers).  The example on my website covers the pessimistic (with
> timers) approach only.
>
> along with the above solution if it's good too.
>>
>
> I would not recommend putting a technique based on socat/nc/netcat in the
> NUT user documentation, but perhaps under a heading such as "Debugging" it
> would be worth having it in the Developer Guide.
>

would you be kind enough to complete the ticket on Github, so that we track
and address this after 2.7.5?
https://github.com/networkupstools/nut/issues/293

I'm intending to finally release it soon, and to have more doc improvement
for the next release.
And your help is definitely welcome!

thanks and cheers,
Arno
-- 
Eaton Data Center Automation Solutions - Opensource Leader -
http://42ity.org
NUT (Network UPS Tools) Project Leader - http://www.networkupstools.org
Debian Developer - http://www.debian.org
Free Software Developer - http://arnaud.quette.fr
___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser