On Sat, 4 Jun 2016, Charles Lepple wrote:> On Jun 3, 2016, at 6:48 AM, Roger Price <roger at rogerprice.org> wrote: >> ... the timer. I don't see it in /var/lib/ups where the locate tool >> finds upsd.pid, and I don't see it in /run or /var/run where I see >> upsmon.pid. >> > ... it seems that the timers are only stored in memory. See > checktimers(): > https://github.com/networkupstools/nut/blob/master/clients/upssched.c#L129Hello Charles, thanks for the link. If timers are only stored in memory then the example given at http://networkupstools.org/docs/user-manual.chunked/ar01s07.html chapter 7.2 is wrong. It is not possible to turn off a timer with rm as shown in #! /bin/sh case $1 in ... ups-back-on-power) /bin/rm -f /some/path/ups-on-battery ;; ... esac This would explain the problem I have with a current script. Is there some other way of forcing routine cancel_timer from a script or a configuration file? Roger
> On Jun 5, 2016, at 6:34 AM, Roger Price <roger at rogerprice.org> wrote: > > On Sat, 4 Jun 2016, Charles Lepple wrote: > >> On Jun 3, 2016, at 6:48 AM, Roger Price <roger at rogerprice.org> wrote: >>> ... the timer. I don't see it in /var/lib/ups where the locate tool finds upsd.pid, and I don't see it in /run or /var/run where I see upsmon.pid. >>> >> ... it seems that the timers are only stored in memory. See checktimers(): https://github.com/networkupstools/nut/blob/master/clients/upssched.c#L129 > > Hello Charles, thanks for the link. If timers are only stored in memory then the example given at http://networkupstools.org/docs/user-manual.chunked/ar01s07.html chapter 7.2 is wrong. It is not possible to turn off a timer with rm as shown inI think that "rm" corresponds to the file mentioned in the phrase "To enable this we could, at the same time, create a file which is read and displayed to any user trying to login whilst the UPS is on battery power." I would agree that the code to create that file is missing from the example, though. Issue: https://github.com/networkupstools/nut/issues/293> This would explain the problem I have with a current script. > > Is there some other way of forcing routine cancel_timer from a script or a configuration file?Again, I don't use upssched myself, but my understanding is that timers are internal to upssched, and the only way to cancel them is through an event listed in the configuration file. I think the intent of the timers was to allow simple filtering of transient events. With a lot of conditionals, I would want a better way to estimate test coverage (at the system level) for all of the possible events and decisions. -- Charles Lepple clepple at gmail
Hi Roger, reviving this discussion, since we have a Github ticket for 2.7.5: https://github.com/networkupstools/nut/issues/293 2016-06-05 12:34 GMT+02:00 Roger Price <roger at rogerprice.org>:> On Sat, 4 Jun 2016, Charles Lepple wrote: > > On Jun 3, 2016, at 6:48 AM, Roger Price <roger at rogerprice.org> wrote: >> >>> ... the timer. I don't see it in /var/lib/ups where the locate tool >>> finds upsd.pid, and I don't see it in /run or /var/run where I see >>> upsmon.pid. >>> >>> ... it seems that the timers are only stored in memory. See >> checktimers(): https://github.com/networkupst >> ools/nut/blob/master/clients/upssched.c#L129 >> > > Hello Charles, thanks for the link. If timers are only stored in memory > then the example given at http://networkupstools.org/doc > s/user-manual.chunked/ar01s07.html chapter 7.2 is wrong. It is not > possible to turn off a timer with rm as shown in > > #! /bin/sh > case $1 in > ... > ups-back-on-power) > /bin/rm -f /some/path/ups-on-battery > ;; > ... > esac > > This would explain the problem I have with a current script. >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> 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? 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20170321/c665d27f/attachment.html>
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