[Nut-upsdev] /sbin/upsdrvctl unable to shutdown UPS ...
Alfred Ganz
alfred-ganz+nut at agci.com
Sun Aug 9 21:48:59 UTC 2009
Charles,
Subject: Re: [Nut-upsdev] /sbin/upsdrvctl unable to shutdown UPS ...
Date: Sun, 9 Aug 2009 16:00:49 -0400
I don't think I explained this correctly the last time, but there is a
potential race condition with some UPSes if the power returns after
the delayed shutdown command is sent. At that point, the machine is
committed to shutting down, so the UPS needs to turn off the outlets
as commanded. But since the power has returned, the UPS can power the
outlets back on after a few seconds.
Note that the current halt script is also used for reboot, and in that
case it runs to the end of the script, where it executes either a reboot
or a halt command. However, it only arrives at the real end if the power
was not shut off by that time. So when an immediate UPS shutdown command
is issued I assume nothing more will happen (yes I don't know how much
further code may be executed, but whatever is still executed could just
as well not be executed). Note that the UPS shutdown command is heavily
guarded by:
if [ "$command" = /sbin/halt -a -r /etc/ups/upsmon.conf -a \
-f /etc/killpower -a -f /etc/sysconfig/ups ] ; then
I would presume that the UPS shutdown would still be done in the halt
script, and that once the UPS is committed to shut down, the halt script
would have to run to the point where currently the immediate ups shutdown
command is issued. I believe one could avoid the race condition by an
appropriate sleep at the point of the immediate UPS shut down command. The
sleep would have to cover the delay of the UPS shutdown and any possible
overrun execution (see above). The sleep would then only complete if power
remained on. At that point it would be safe to switch to reboot mode. The
significant difference being of course that both the sleep and setting
reboot mode only require what is available at that point.
>Note1, since nut removes itself from the hid device, I presume that
>this
> involves removal of any corresponding /dev entries (in any case
> I see none on my system, there are two entries for the UPS:
> /dev/usbdev2.2_ep00 and /dev/usbdev2.2_ep81).
I was asking hypothetically, if the NUT code were changed to use /dev/
hiddev* instead of /proc/bus/usb or /dev/bus/usb.
Sorry, I don't really know how hid devices are handled. Also, there don't
seem to be any udev rules for such devices.
AG
--
----------------------------------------------------------------------
Alfred Ganz alfred-ganz:at:agci.com
AG Consulting, Inc. (203) 624-9667
440 Prospect Street # 11
New Haven, CT 06511
----------------------------------------------------------------------
More information about the Nut-upsdev
mailing list