[Nut-upsuser] Is a timer a file?

[Arnaud Quette]

Hi Roger,

2017-03-28 15:07 GMT+02:00 Roger Price <roger at rogerprice.org>:

> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20170404/82904709/attachment.html>