[Nut-upsuser] Is a timer a file?
Roger Price
roger at rogerprice.org
Tue Mar 28 13:07:00 UTC 2017
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
More information about the Nut-upsuser
mailing list