Package: nut
Version: 2.7.2-4
Severity: important
After an emergency shutdown due to power loss, the command to kill the
power is never sent to the UPS. And since all the machines are powered
down, the load is zero, so this will continue for a pretty long time,
during which power is very likely to return. Because of this, not only
do the connected machines require a manual power-on, but the UPS and the
battery may be damaged (batteries do not like discharging completely,
and UPS-es do not like overheating due to operating at low wattages,
according to their manuals).
I know that NUT has a workaround for this situation for UPS-es that do
not support killing the power (POWEROFF_WAIT). However, people KNOW that
their UPS DOES support it, so they will not have it turned on. And even
if they do a test run (and does everyone do a completely real power
failure test run after an upgrade to Jessie from a perfectly working
Wheezy installation?), they may not be patient enough to wait until the
UPS cuts the power automatically, because the timeout may be set to
something pretty long.
My investigation revealed that the power kill command is supposed to be
sent by /lib/systemd/system-shutdown/nutshutdown (which is really
neither obvious nor documented, as far as I could find, but oh well):
/sbin/upsmon -K >/dev/null 2>&1 && /sbin/upsdrvctl shutdown
However, /sbin/upsmon -K ALWAYS returns false, even if the flag is there
(I've tried replacing "/sbin/upsdrvctl shutdown" with a debug command
and it never got executed).
Changing that line to "if [ -f /etc/killpower ] ; then /sbin/upsdrvctl
shutdown ; fi" fixes the problem for me.
I do not know why does upsmon -K not work as intended, but there are
many possible reasons:
- it likes to complain that "the file is there, but I can't read it, so
what if there's no magic word?! I won't do it without the magic word!"
- it likes to complain that "one UPSMON is already running" (and systemd
seems to be particularly good at starting upsmon when it's not needed
and not being able to stop it when you try to do that)
- maybe some other permission problems between "root" and "nut" (see:
https://bugs.launchpad.net/ubuntu/+source/nut/+bug/839490
and
http://askubuntu.com/questions/511387/nut-not-shutting-down-ups-does-14-04-server-block-usb-comms-in-runlevel-0
)
-- System Information:
Debian Release: 8.5
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.1.18-aufs (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages nut depends on:
ii nut-client 2.7.2-4
ii nut-server 2.7.2-4
nut recommends no packages.
nut suggests no packages.
-- no debconf information
--
darkpenguin
