[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 

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