Hi Charles,

On 10/12/14 14:27, Charles Lepple wrote:
Hi Andy,

On Dec 8, 2014, at 7:07 PM, Andy Juniper <[email protected]> wrote:

It adds a signal handler for the USR1 signal, which simply triggers it to abort 
the current sleep and log the requested now.
I will admit that I'm not an expert on how signals interrupt system calls on 
all systems, but for what it's worth, the code looks good to me. Is it correct 
to assume that you are using this on Linux?
Yes, I've been running this on an ancient RedHat 9 system for a few years, and I'm just in the process of moving it to EL6. Certainly on Linux, the signal interrupts the sleep which returns with (quoting from the manual page):

   RETURN VALUE
           Zero if the requested time has elapsed, or the number of
   seconds left to sleep, if the call was interrupted by a signal handler.

I find it useful because my upssched-cmd can then killall -USR1 upslog to 
ensure that there is an entry in the log for brief power dropouts which would 
otherwise be unrecorded (because the power is only off for a few seconds).
Agreed, that sounds very useful.

I don't think we have a standard format for documenting the signals that the 
various NUT components respond to. However, I wouldn't want this feature to 
remain undocumented. Would you mind writing up a paragraph for the man page, in 
docs/man/upslog.txt? We currently describe how the sleep(3) times are 
approximate, but this could go in there as well.
Try this - I couldn't see the file you reference but here's a paragraph for the manual page - probably fits in after service delays or log rotation.

   ON DEMAND LOGGING
   Sending a USR1 signal to a running 'upslog' process makes it wake
   from the current sleep and log immediately.  This is useful when
   triggered from a upssched event trigger (e.g. AT ONBATT or AT
   ONLINE) to ensure that an entry always exists, even if the power
   goes away for a period of time shorter than that specified by the -i
   argument.

Andy

Thanks,


_______________________________________________
Nut-upsdev mailing list
[email protected]
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev

Reply via email to