[Pkg-sysvinit-devel] Bug#577146: Bug#577146: marked as done (Logic of halt script, with regard to ups-monitor, is wrong)

[Henrique de Moraes Holschuh]

On Fri, 11 Jun 2010, Debian Bug Tracking System wrote:
> Package: sysvinit
> Version: 2.87dsf-10
> Severity: important
> Tags: patch
> 
>   Suppose a user set HALT=poweroff in /etc/default/halt, and also
> set /etc/init.d/ups-monitor because he has a ups.  With the current
> halt script, won't the end result be that the ups will always be 
> requested to cut the power?

WARNING: UPS control has many pitfalls, and if you get it wrong, you will
cause a lot of issues for people using Debian on servers.

Non-broken auto-restart UPS setups *always* power-cycle the load after a
given guard time [after power has been restored and battery levels are safe
again] once the host has acked the criticial battery alarm with a "will
powerdown" message to the UPS.

That behaviour is used to make sure that the scenario "critical battery
alarm -> system shutdown requested -> past point of no-return from shutdown
-> power restored -> system poweroff" doesn't leave the system powered off.
It is also the *only* race-free way to do it.  ups-monitor poweroff is used
to send that ACK message to the UPS (which is not an ACK message, but rather
the "please power off the load until battery charge is again above x%"
command :p).  We should issue it AFTER the point of no return (which in
sysv-rc is basically as soon as we start switching to runlevel 0).

We have taken the instance of issuing it AFTER a point where we think it is
safer to lose power, the reasoning being that it is best for the host to get
stuck on the shutdown sequence without the power-cycle (should power get
back *AND* the shutdown sequence get stuck), than for it to lose power due
to the mandatory power cycle before umounting filesystems, etc. should the
shutdown sequence get stuck.   i.e. it is only relevant on failure modes
where something hangs instead of proceding with the shutdown.

So, whatever we do to halt and ups-monitor calls MUST preserve the above
flux.  If that's not what is being done, we need to fix it... it has been
some time since I last tested it.

> --- halt        2010-04-10 05:24:57.000000000 +0200
> +++ halt.mod    2010-04-10 05:25:37.000000000 +0200
> @@ -17,6 +17,12 @@
>  . /lib/lsb/init-functions
> 
>  do_stop () {
> +       # See if we need to cut the power.
> +       if [ "$INIT_HALT" = "POWEROFF" ] && [ -x /etc/init.d/ups-monitor ]
> +       then
> +               /etc/init.d/ups-monitor poweroff
> +       fi
> +
>         if [ "$INIT_HALT" = "" ]
>         then
>                 case "$HALT" in
> @@ -32,12 +38,6 @@
>                 esac
>         fi
> 
> -       # See if we need to cut the power.
> -       if [ "$INIT_HALT" = "POWEROFF" ] && [ -x /etc/init.d/ups-monitor ]
> -       then
> -               /etc/init.d/ups-monitor poweroff
> -       fi
> -
>         # Don't shut down drives if we're using RAID.
>         hddown="-h"
>         if grep -qs '^md.*active' /proc/mdstat


As for this bug being closed:
>    * Drop soft dependency from init.d/bootlogs to gdm3 until gdm3 stop
>      depending on bootlogs, to avoid init.d script loop (Closes: #577146).

Huh?  Looks like the wrong bug number in that changelog entry...

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh