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
[email protected]
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
