[Nut-upsuser] Is a timer a file?
arnaud.quette at gmail.com
Tue Apr 4 11:14:41 UTC 2017
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 -
> 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.
would you be kind enough to complete the ticket on Github, so that we track
and address this after 2.7.5?
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,
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...
More information about the Nut-upsuser