[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