We have the same problem and present below some possible solutions.
ASSUMPTION: Your computer's BIOS is set to "Last State After Power
Loss", i.e., it will turn back on iff it lost power after system halt.
On some computers, if your BIOS is set to "Always On After Power Loss",
this bug report may *also* apply, because on some computers, if you do a
clean shutdown and poweroff, if you then pull the plug and then plug
back in, the computer will remain off.
If /etc/default/halt has HALT=poweroff, then:
0) Power goes out. UPS starts beeping. apcupsd kicks into gear!
1) /etc/init.d/halt will set INIT_HALT to POWEROFF
2) /etc/init.d/halt will indeed call /etc/init.d/ups-monitor
3) /etc/init.d/ups-monitor will tell the UPS to cut power within ~90
seconds
4) /etc/init.d/halt will tell the computer to poweroff completely
5) When power is restored, the computer does *not* turn back on,
because BIOS saw the clean poweroff and thus does *not* view this as a
Power Loss situation.
6) Power is restored but computer remains off. PROBLEM!
If /etc/default/halt has HALT=halt, then:
0) Power goes out. UPS starts beeping. apcupsd kicks into gear!
1) /etc/init.d/halt will set INIT_HALT to HALT
2) /etc/init.d/halt will *not* call /etc/init.d/ups-monitor
3) /etc/init.d/halt will tell the computer to go into system halt
(not poweroff)
4) Computer remains on, and UPS continues to drain.
5) If the UPS eventually runs out of juice and dies, so that computer
loses power, then when power is later restored, the computer will turn
back on.
6) However, if power is restored before UPS drains out, then the
computer remains in system halt state forever. PROBLEM!
SUMMARY THUS FAR: No matter what you put in /etc/default/halt, you will
have a PROBLEM!
Possible solutions:
1) The /etc/init.d/halt script could be changed (note that it is part
of 'initscripts', not part of 'apcupsd', and fortunately is marked as a
conffile, so a sysadmin can modify it and won't quietly lose those
changes during an upgrade) to set INIT_HALT to HALT after calling
ups-monitor:
if [ "$INIT_HALT" = "POWEROFF" ] && [ -x /etc/init.d/ups-monitor ]
then
/etc/init.d/ups-monitor poweroff
INIT_HALT=HALT #### THIS LINE WAS ADDED ####
fi
2) An alternate change is to have it *always* call ups-monitor, i.e.,
remove the test for INIT_HALT being POWEROFF, but then make sure
/etc/default/halt has HALT=halt:
Old: if [ "$INIT_HALT" = "POWEROFF" ] && [ -x /etc/init.d/ups-monitor ]
New: if [ -x /etc/init.d/ups-monitor ]
3) Ultimately, though, the /etc/init.d/halt script should have a way
to communicate with /etc/init.d/ups-monitor to find out the situation.
In other words, ups-monitor should return a value indicating whether the
UPS will cut power, whether power was already restored, etc., and
perhaps indicating what should happen next: merely halt the system, also
do a poweroff, or in fact do a restart?
See Debian bugs #55123 and #293401 for related discussions in regards
to other UPS packages with similar issues. It seems the initscripts
maintainers don't want to make changes unless *all* UPS package
developers join in the discussion. The goal seems to be to find a common
solution in initscripts that will work with all UPS packages.
Alexander Perlis, Department of Mathematics, The University of Arizona
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
