[Nut-upsdev] Important regression in usbhid-ups (r1113)
Peter Selinger
selinger at mathstat.dal.ca
Thu Feb 21 23:34:03 UTC 2008
Arjen de Korte wrote:
>
> > Also, in my opinion, a default offdelay of 20 seconds is useless.
> > The default offdelay should be 0 seconds, because normally one shuts
> > down the UPS as the last step in the computer's shutdown sequence.
>
> This has been discussed to death long before. Summary is, that there are
> worries that the hardware (disk drives mostly) may be damaged if you
> suddenly remove power and it would be easier on the hardware if you allow
> some time *after* sending the shutdown command to allow the attached
> system to do it's system poweroff. Therefor, the delay should never be
> zero by default (since that might be 'dangerous') and a delay of 20
> seconds was chosen. If the UPS can't provide power long enough, nothing is
> lost here, because the device was already going down anyway. If that's not
> what you like, set 'offdelay = 0' in 'ups.conf'.
Interesting. I missed this discussion. I didn't miss line 493 of the
file INSTALL though, which recommends a different behavior than what
you describe:
You should configure your system to power down the UPS after the
filesystems are remounted read-only. Have it look for the presence
of the POWERDOWNFLAG (from upsmon.conf), using this as an example:
if (test -f /etc/killpower)
then
echo "Killing the power, bye!"
/usr/local/ups/bin/upsdrvctl shutdown
sleep 120
# uh oh... the UPS power-off failed
# you probably want to reboot here so you don't get
# stuck!
# *** see the section on power races in shutdown.txt!
# ***
fi
Here, there is no talk of executing the native poweroff command.
What you describe would take the form something like the following:
if (test -f /etc/killpower)
then
echo "Scheduling power supply to shut off in 20 seconds"
/usr/local/ups/bin/upsdrvctl shutdown
fi
echo "Killing the power, bye!"
/sbin/halt
But this method has its own drawbacks: if the UPS in fact fails to power
off, then the system will not reboot without human (and physical!)
intervention. This kind of thing has happened to me often - during
testing, and more importantly, after upgrading. Perhaps a missing USB
bus, /usr/local not mounted, a driver has been renamed in a new NUT
version and upsdrvctl refuses to recognize its configuration file, or any
such similar problem. It's amazing how often I have actually used the
"you probably want to reboot here" scenario.
-- Peter
More information about the Nut-upsdev
mailing list