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

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

[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.


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-21 19:34 GMT+01:00 Roger Price :

> On Tue, 21 Mar 2017, Arnaud Quette wrote:
>
> Hi Roger,
>>
>> reviving this discussion, since we have a Github ticket for 2.7.5:
>> https://github.com/networkupstools/nut/issues/293
>>
> ...
>
>> I've made some additions to clarify things on the timer, and complete the
>> script:
>> https://github.com/networkupstools/nut/compare/upssched-doc?expand=1
>>
>
> Hi Arnaud, Your change to the documentation clears up what I had
> mis-understood.  The new text makes it clear that the upssched timers are
> an in-memory device, and that they can only be turned on and off with
> upssched.conf declarations such as
>
> AT ONBATT * START-TIMER onbattwarn 30
> AT ONLINE * CANCEL-TIMER onbattwarn
>

thanks for your confirmation. I'll check to merge that PR.


>   Is there some other way of forcing routine cancel_timer from a
>> script or a configuration file?
>>
>> this is the last point to address, but I'd need to better understand
>> prior to potentially taking action:
>> theoretically, each event that triggers a timer (like ONBATT) has a
>> counterpart to cancel it (like ONLINE).
>> Ex (from the doc):
>> AT ONBATT * START-TIMER onbattwarn 30
>> AT ONLINE * CANCEL-TIMER onbattwarn
>>
>> So is there any use case we're missing here?
>>
>
> My use case was for a UPS unit which gave transient stupid status changes
> such as "OL DISCHARG CHARG LB" when the battery was 100% charged.  It was
> an old MGE unit which has since died.
>
> When the stupid status change occured, the LB began a system shutdown.  To
> overcome this unwanted stutdown, I wanted to start a 5 second timer, and
> when this ran out, upssched-cmd would review the situation, and decide if a
> shutdown was really needed.  If it was not needed, I had to cancel the
> system-shutdown timer.  I mistakenly assumed that such a timer was a file,
> and that it was sufficient to erase the file.
>
> To solve the problem of cancelling an arbitrary timer from a script such
> as upssched-cmd, I submitted a proposal to nut-upsdev:
>
>[Nut-upsdev] Proposal for technique to stop a timer at any moment
> https://lists.alioth.debian.org/pipermail/nut-upsdev/2016-July/007202.html
>
> and a set of patches :
>
> https://lists.alioth.debian.org/pipermail/nut-upsdev/2016-July/007203.html
> https://lists.alioth.debian.org/pipermail/nut-upsdev/2016-July/007204.html
>
> 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?
>

Thanks for sharing your use case, and the rationales behind.
First, the base point is to be able to cancel a timer anytime, from a
command-line, which makes sense (as an extension, the opposite may also be
true, to start a timer lively, without the event coming from upsmon).

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.

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

Please tell me back if such solution would make it for you.

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, along with the above solution if it's
good too.

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] Is a timer a file?

[Roger Price]

On Tue, 21 Mar 2017, Arnaud Quette wrote:


Hi Roger,

reviving this discussion, since we have a Github ticket for 2.7.5:
https://github.com/networkupstools/nut/issues/293
... 

I've made some additions to clarify things on the timer, and complete the 
script:
https://github.com/networkupstools/nut/compare/upssched-doc?expand=1


Hi Arnaud, Your change to the documentation clears up what I had 
mis-understood.  The new text makes it clear that the upssched timers are 
an in-memory device, and that they can only be turned on and off with 
upssched.conf declarations such as


    AT ONBATT * START-TIMER onbattwarn 30
    AT ONLINE * CANCEL-TIMER onbattwarn


  Is there some other way of forcing routine cancel_timer from a script or 
a configuration file?

this is the last point to address, but I'd need to better understand prior to 
potentially taking action:
theoretically, each event that triggers a timer (like ONBATT) has a counterpart 
to cancel it (like ONLINE).
Ex (from the doc):
    AT ONBATT * START-TIMER onbattwarn 30
    AT ONLINE * CANCEL-TIMER onbattwarn

So is there any use case we're missing here?


My use case was for a UPS unit which gave transient stupid status changes 
such as "OL DISCHARG CHARG LB" when the battery was 100% charged.  It was 
an old MGE unit which has since died.


When the stupid status change occured, the LB began a system shutdown.  To 
overcome this unwanted stutdown, I wanted to start a 5 second timer, and 
when this ran out, upssched-cmd would review the situation, and decide if 
a shutdown was really needed.  If it was not needed, I had to cancel the 
system-shutdown timer.  I mistakenly assumed that such a timer was a file, 
and that it was sufficient to erase the file.


To solve the problem of cancelling an arbitrary timer from a script such 
as upssched-cmd, I submitted a proposal to nut-upsdev:


   [Nut-upsdev] Proposal for technique to stop a timer at any moment
https://lists.alioth.debian.org/pipermail/nut-upsdev/2016-July/007202.html

and a set of patches :

https://lists.alioth.debian.org/pipermail/nut-upsdev/2016-July/007203.html
https://lists.alioth.debian.org/pipermail/nut-upsdev/2016-July/007204.html

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?

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,

reviving this discussion, since we have a Github ticket for 2.7.5:
https://github.com/networkupstools/nut/issues/293

2016-06-05 12:34 GMT+02:00 Roger Price :

> On Sat, 4 Jun 2016, Charles Lepple wrote:
>
> On Jun 3, 2016, at 6:48 AM, Roger Price  wrote:
>>
>>> ... the timer.  I don't see it in /var/lib/ups where the locate tool
>>> finds upsd.pid, and I don't see it in /run or /var/run where I see
>>> upsmon.pid.
>>>
>>> ... it seems that the timers are only stored in memory. See
>> checktimers(): https://github.com/networkupst
>> ools/nut/blob/master/clients/upssched.c#L129
>>
>
> Hello Charles, thanks for the link.  If timers are only stored in memory
> then the example given at http://networkupstools.org/doc
> s/user-manual.chunked/ar01s07.html chapter 7.2 is wrong.  It is not
> possible to turn off a timer with rm as shown in
>
> #! /bin/sh
> case $1 in
> ...
> ups-back-on-power)
> /bin/rm -f /some/path/ups-on-battery
> ;;
> ...
> esac
>
> This would explain the problem I have with a current script.
>

I've made some additions to clarify things on the timer, and complete the
script:
https://github.com/networkupstools/nut/compare/upssched-doc?expand=1


> Is there some other way of forcing routine cancel_timer from a script or a
> configuration file?
>

this is the last point to address, but I'd need to better understand prior
to potentially taking action:
theoretically, each event that triggers a timer (like ONBATT) has a
counterpart to cancel it (like ONLINE).
Ex (from the doc):
AT ONBATT * START-TIMER onbattwarn 30
AT ONLINE * CANCEL-TIMER onbattwarn

So is there any use case we're missing here?

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] Is a timer a file?

[Charles Lepple]

> On Jun 5, 2016, at 6:34 AM, Roger Price  wrote:
> 
> On Sat, 4 Jun 2016, Charles Lepple wrote:
> 
>> On Jun 3, 2016, at 6:48 AM, Roger Price  wrote:
>>> ... the timer.  I don't see it in /var/lib/ups where the locate tool finds 
>>> upsd.pid, and I don't see it in /run or /var/run where I see upsmon.pid.
>>> 
>> ... it seems that the timers are only stored in memory. See checktimers(): 
>> https://github.com/networkupstools/nut/blob/master/clients/upssched.c#L129
> 
> Hello Charles, thanks for the link.  If timers are only stored in memory then 
> the example given at 
> http://networkupstools.org/docs/user-manual.chunked/ar01s07.html chapter 7.2 
> is wrong.  It is not possible to turn off a timer with rm as shown in

I think that "rm" corresponds to the file mentioned in the phrase "To enable 
this we could, at the same time, create a file which is read and displayed to 
any user trying to login whilst the UPS is on battery power."

I would agree that the code to create that file is missing from the example, 
though.

Issue: https://github.com/networkupstools/nut/issues/293

> This would explain the problem I have with a current script.
> 
> Is there some other way of forcing routine cancel_timer from a script or a 
> configuration file?

Again, I don't use upssched myself, but my understanding is that timers are 
internal to upssched, and the only way to cancel them is through an event 
listed in the configuration file.

I think the intent of the timers was to allow simple filtering of transient 
events. With a lot of conditionals, I would want a better way to estimate test 
coverage (at the system level) for all of the possible events and decisions.

-- 
Charles Lepple
clepple@gmail




___
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?

[Roger Price]

On Sat, 4 Jun 2016, Charles Lepple wrote:


On Jun 3, 2016, at 6:48 AM, Roger Price  wrote:
... the timer.  I don't see it in /var/lib/ups where the locate tool 
finds upsd.pid, and I don't see it in /run or /var/run where I see 
upsmon.pid.


... it seems that the timers are only stored in memory. See 
checktimers(): 
https://github.com/networkupstools/nut/blob/master/clients/upssched.c#L129


Hello Charles, thanks for the link.  If timers are only stored in memory 
then the example given at 
http://networkupstools.org/docs/user-manual.chunked/ar01s07.html chapter 
7.2 is wrong.  It is not possible to turn off a timer with rm as shown in


#! /bin/sh
case $1 in
...
ups-back-on-power)
/bin/rm -f /some/path/ups-on-battery
;;
...
esac

This would explain the problem I have with a current script.

Is there some other way of forcing routine cancel_timer from a script or a 
configuration file?


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?

[Charles Lepple]

On Jun 3, 2016, at 6:48 AM, Roger Price  wrote:
> 
> Hi, I'm trying to get a better understanding of what a timer is, so I added 
> the following line to upssched.conf
> 
> # Debug - turn on long-running timer to find out where upssched puts it
> AT ONBATT * START-TIMER where-am-I 1000
> 
> I can then start this timer by pulling the power cord from the wall for just 
> a few seconds.

(Incidentally, this sounds like a good use case for the dummy-ups driver - you 
could just edit the ups.status line in the dump file, and upssched could follow 
the simulated UPS.)

> I now have 1000 seconds to find the timer.  I don't see it in /var/lib/ups 
> where the locate tool finds upsd.pid, and I don't see it in /run or /var/run 
> where I see upsmon.pid.
> 
> Is a timer a file?, and if it is, where should I find it?  Any suggestion 
> would be much appreciated.  Thanks, Roger

I don't use upssched myself, but from looking at the code, it seems that the 
timers are only stored in memory. See checktimers(): 
https://github.com/networkupstools/nut/blob/master/clients/upssched.c#L129

-- 
Charles Lepple
clepple@gmail




___
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?

[e430benz98]

Just tried 2.7.4 Tripp Lite SMART1300LCD still doesn't work 

Sent from my LG G3.

-Original Message-
From: Roger Price <ro...@rogerprice.org>
To: nut-upsuser Mailing List <nut-upsuser@lists.alioth.debian.org>
Sent: Fri, 03 Jun 2016 3:48 AM
Subject: [Nut-upsuser] Is a timer a file?

Hi, I'm trying to get a better understanding of what a timer is, so I 
added the following line to upssched.conf

  # Debug - turn on long-running timer to find out where upssched puts it
  AT ONBATT * START-TIMER where-am-I 1000

I can then start this timer by pulling the power cord from the wall for 
just a few seconds.

I now have 1000 seconds to find the timer.  I don't see it in /var/lib/ups 
where the locate tool finds upsd.pid, and I don't see it in /run or 
/var/run where I see upsmon.pid.

Is a timer a file?, and if it is, where should I find it?  Any suggestion 
would be much appreciated.  Thanks, Roger

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

[Nut-upsuser] Is a timer a file?

[Roger Price]

Hi, I'm trying to get a better understanding of what a timer is, so I 
added the following line to upssched.conf


 # Debug - turn on long-running timer to find out where upssched puts it
 AT ONBATT * START-TIMER where-am-I 1000

I can then start this timer by pulling the power cord from the wall for 
just a few seconds.


I now have 1000 seconds to find the timer.  I don't see it in /var/lib/ups 
where the locate tool finds upsd.pid, and I don't see it in /run or 
/var/run where I see upsmon.pid.


Is a timer a file?, and if it is, where should I find it?  Any suggestion 
would be much appreciated.  Thanks, Roger


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