[Nut-upsuser] Is a timer a file?

Arnaud Quette arnaud.quette at gmail.com
Wed Mar 22 14:10:59 UTC 2017

Hi Roger

2017-03-21 19:34 GMT+01:00 Roger Price <roger at rogerprice.org>:

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

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.

Eaton Data Center Automation Solutions - Opensource Leader -
NUT (Network UPS Tools) Project Leader - http://www.networkupstools.org
Debian Developer - http://www.debian.org
Free Software Developer - http://arnaud.quette.fr
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20170322/d4b2dbeb/attachment-0001.html>

More information about the Nut-upsuser mailing list