On Tue, 21 Mar 2017, Arnaud Quette wrote:> Hi Roger, > > reviving this discussion, since we have a Github ticket for 2.7.5: > https://github.com/networkupstools/nut/issues/293...> I've made some additions to clarify things on the timer, and complete the script: > https://github.com/networkupstools/nut/compare/upssched-doc?expand=1Hi Arnaud, Your change to the documentation clears up what I had mis-understood. The new text makes it clear that the upssched timers are an in-memory device, and that they can only be turned on and off with upssched.conf declarations such as ??? AT ONBATT * START-TIMER onbattwarn 30 ??? AT ONLINE * CANCEL-TIMER onbattwarn> Is there some other way of forcing routine cancel_timer from a script or a configuration file? > > this is the last point to address, but I'd need to better understand prior to potentially taking action: > theoretically, each event that triggers a timer (like ONBATT) has a counterpart to cancel it (like ONLINE). > Ex (from the doc): > ??? AT ONBATT * START-TIMER onbattwarn 30 > ??? AT ONLINE * CANCEL-TIMER onbattwarn > > So is there any use case we're missing here?My use case was for a UPS unit which gave transient stupid status changes such as "OL DISCHARG CHARG LB" when the battery was 100% charged. It was an old MGE unit which has since died. When the stupid status change occured, the LB began a system shutdown. To overcome this unwanted stutdown, I wanted to start a 5 second timer, and when this ran out, upssched-cmd would review the situation, and decide if a shutdown was really needed. If it was not needed, I had to cancel the system-shutdown timer. I mistakenly assumed that such a timer was a file, and that it was sufficient to erase the file. To solve the problem of cancelling an arbitrary timer from a script such as upssched-cmd, I submitted a proposal to nut-upsdev: [Nut-upsdev] Proposal for technique to stop a timer at any moment https://lists.alioth.debian.org/pipermail/nut-upsdev/2016-July/007202.html and a set of patches : https://lists.alioth.debian.org/pipermail/nut-upsdev/2016-July/007203.html https://lists.alioth.debian.org/pipermail/nut-upsdev/2016-July/007204.html 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? Roger
Hi Roger 2017-03-21 19:34 GMT+01:00 Roger Price <roger at rogerprice.org>:> On Tue, 21 Mar 2017, Arnaud Quette wrote: > > Hi Roger, >> >> reviving this discussion, since we have a Github ticket for 2.7.5: >> https://github.com/networkupstools/nut/issues/293 >> > ... > >> I've made some additions to clarify things on the timer, and complete the >> script: >> https://github.com/networkupstools/nut/compare/upssched-doc?expand=1 >> > > Hi Arnaud, Your change to the documentation clears up what I had > mis-understood. The new text makes it clear that the upssched timers are > an in-memory device, and that they can only be turned on and off with > upssched.conf declarations such as > > AT ONBATT * START-TIMER onbattwarn 30 > AT ONLINE * CANCEL-TIMER onbattwarn >thanks for your confirmation. I'll check to merge that PR.> Is there some other way of forcing routine cancel_timer from a >> script or a configuration file? >> >> this is the last point to address, but I'd need to better understand >> prior to potentially taking action: >> theoretically, each event that triggers a timer (like ONBATT) has a >> counterpart to cancel it (like ONLINE). >> Ex (from the doc): >> AT ONBATT * START-TIMER onbattwarn 30 >> AT ONLINE * CANCEL-TIMER onbattwarn >> >> So is there any use case we're missing here? >> > > My use case was for a UPS unit which gave transient stupid status changes > such as "OL DISCHARG CHARG LB" when the battery was 100% charged. It was > an old MGE unit which has since died. > > When the stupid status change occured, the LB began a system shutdown. To > overcome this unwanted stutdown, I wanted to start a 5 second timer, and > when this ran out, upssched-cmd would review the situation, and decide if a > shutdown was really needed. If it was not needed, I had to cancel the > system-shutdown timer. I mistakenly assumed that such a timer was a file, > and that it was sufficient to erase the file. > > To solve the problem of cancelling an arbitrary timer from a script such > as upssched-cmd, I submitted a proposal to nut-upsdev: > > [Nut-upsdev] Proposal for technique to stop a timer at any moment > https://lists.alioth.debian.org/pipermail/nut-upsdev/2016-July/007202.html > > and a set of patches : > > https://lists.alioth.debian.org/pipermail/nut-upsdev/2016-July/007203.html > https://lists.alioth.debian.org/pipermail/nut-upsdev/2016-July/007204.html > > 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? >Thanks for sharing your use case, and the rationales behind. First, the base point is to be able to cancel a timer anytime, from a command-line, which makes sense (as an extension, the opposite may also be true, to start a timer lively, without the event coming from upsmon). 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. 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 Please tell me back if such solution would make it for you. 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, along with the above solution if it's good too. 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20170322/d4b2dbeb/attachment-0001.html>
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.pipeWhat 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