Hi Roger, 2017-03-28 15:07 GMT+02:00 Roger Price <ro...@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
_______________________________________________ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser