Debian Bug report logs - #55123
Please improve UPS support

Package: initscripts; Maintainer for initscripts is Debian sysvinit maintainers <pkg-sysvinit-devel@lists.alioth.debian.org>; Source for initscripts is src:sysvinit.

Reported by: Peter S Galbraith <psg@debian.org>

Date: Sat, 15 Jan 2000 00:54:00 UTC

Severity: wishlist

Tags: wontfix

Done: Roger Leigh <rleigh@codelibre.net>

Bug is archived. No further changes may be made.

Toggle useless messages

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to debian-bugs-dist@lists.debian.org, Peter S Galbraith <psg@debian.org>:
Bug#55123; Package powstatd. Full text and rfc822 format available.

Acknowledgement sent to Peter S Galbraith <GalbraithP@dfo-mpo.gc.ca>:
New Bug report received and forwarded. Copy sent to Peter S Galbraith <psg@debian.org>. Full text and rfc822 format available.

Message #5 received at submit@bugs.debian.org (full text, mbox):

From: Peter S Galbraith <GalbraithP@dfo-mpo.gc.ca>
To: Mitch Blevins <mblevin@debian.org>, Brian White <bcwhite@pobox.com>, submit@bugs.debian.org
Cc: Peter S Galbraith <GalbraithP@dfo-mpo.gc.ca>
Subject: I think /etc/init.d/powerfail shouldn't be a conffile
Date: Fri, 14 Jan 2000 12:14:47 -0500
Package: powstatd
Version: 1.4.1-3

Hello Mitch and Brian,

I maintain the ups-monitor powstatd and something occurred to me
about /etc/init.d/powerfail.  The bpowerd, genpower and powstatd
all have /etc/init.d/powerfail as a conffile.  When a user tries
installing these packages to see which is best for his UPS, he
might inadvertently use the powerfail script from another
package.

For example:

 - I install powstatd.
 - I remove (but not purge powstatd).
 - I install genpower.
    - if I don't install the package's /etc/init.d/powerfail, I
       use the one from powstatd
 - Suppose I select to keep the package's /etc/init.d/powerfail
 - Then I remove genpower and re-install powstatd
    - if I don't install the package's /etc/init.d/powerfail, I
       use the one from genpower

This is untested, but the fact that we all use the same filename
(no choice about this) implies to me that it should not stick
around after remove (and not purging) the package.

Thoughts?

I'm submitting this as a bug against my own package as a log of
the discussion, if any.  I'm probably going to remove
/etc/init.d/powerfail as a conffile and put whatever configuration
it can have in another conffile, like /etc/init.d/powstatd.
I'll email you both the bug number as soon as I get it, should
you want your comments logged there too.

Peter



Information forwarded to debian-bugs-dist@lists.debian.org, Peter S Galbraith <psg@debian.org>:
Bug#55123; Package powstatd. Full text and rfc822 format available.

Acknowledgement sent to Mitch Blevins <mblevin@debian.org>:
Extra info received and forwarded to list. Copy sent to Peter S Galbraith <psg@debian.org>. Full text and rfc822 format available.

Message #10 received at 55123@bugs.debian.org (full text, mbox):

From: Mitch Blevins <mblevin@debian.org>
To: Peter S Galbraith <GalbraithP@dfo-mpo.gc.ca>
Cc: 55123@bugs.debian.org
Subject: Re: I think /etc/init.d/powerfail shouldn't be a conffile
Date: Fri, 14 Jan 2000 20:35:07 -0500
Peter S Galbraith wrote:
> Thoughts?
> 
> I'm submitting this as a bug against my own package as a log of
> the discussion, if any.  I'm probably going to remove
> /etc/init.d/powerfail as a conffile and put whatever configuration
> it can have in another conffile, like /etc/init.d/powstatd.
> I'll email you both the bug number as soon as I get it, should
> you want your comments logged there too.

This seems reasonable.
Is there any reason to make the conffile an executable script?
For example, would it be better to have /etc/init.d/powerfail
be a non-conffile that sources /etc/bpowerd.conf, which is
a conffile?

Also, is it possible to do this before the freeze?

-Mitch



Information forwarded to debian-bugs-dist@lists.debian.org, Peter S Galbraith <psg@debian.org>:
Bug#55123; Package powstatd. Full text and rfc822 format available.

Acknowledgement sent to Peter S Galbraith <GalbraithP@dfo-mpo.gc.ca>:
Extra info received and forwarded to list. Copy sent to Peter S Galbraith <psg@debian.org>. Full text and rfc822 format available.

Message #15 received at 55123@bugs.debian.org (full text, mbox):

From: Peter S Galbraith <GalbraithP@dfo-mpo.gc.ca>
To: Mitch Blevins <mblevin@debian.org>
Cc: 55123@bugs.debian.org, Peter S Galbraith <GalbraithP@dfo-mpo.gc.ca>, Brian White <bcwhite@pobox.com>
Subject: Re: I think /etc/init.d/powerfail shouldn't be a conffile
Date: Fri, 14 Jan 2000 21:59:30 -0500
Mitch Blevins wrote:

> Peter S Galbraith wrote:
>
> >                          I'm probably going to remove
> > /etc/init.d/powerfail as a conffile and put whatever configuration
> > it can have in another conffile, like /etc/init.d/powstatd.
> 
> This seems reasonable.

Good.

> Is there any reason to make the conffile an executable script?

Not really, except to make it plainly obvious to the end user
(admin) what's doing what.  But good ducumentation can fill the gap.

> For example, would it be better to have /etc/init.d/powerfail
> be a non-conffile that sources /etc/bpowerd.conf, which is
> a conffile?

Sounds good to me.  Or maybe if we all used the _same_
/etc/init.d/powerfail file to make it even simpler for the local
admins.  I know mine is probably very similar to yours, but
genpower checks an extra status file (and we don't).

In my case, the file /etc/powstatd.conf exisit upstream and I
wanted to keep it in the same format.  I have already broken that
a bit by shipping a default /etc/powstatd.conf file that contains
a comment line that must be deleted for the daemon to start (As
confirmation by the admin that the package has in fact been
configured and should be started normally).  In hindsight I
should have put that comment elsewhere, in /etc/init.d/powstatd
itself.  However, once that line is deleted the conffile is
identical to upstream and it's the single file the user _must_
check.  So I'd prefer to put Debian-specific settings in another
file, something like /etc/powstatd.debian.conf.

> Also, is it possible to do this before the freeze?

Man, I don't know.  Perhaps if you upload a new package tonight!
What you can more reasonably do is submit a bug against your
package, prepare a fix, upload it for frozen and hope it get
included at round two (if there is one).  I think trying to force
it in tonight for unstable might not fly.  Maybe I'm wrong.

Peter


Acknowledgement sent to Brian White <bcwhite@pobox.com>:
Extra info received and filed, but not forwarded. Full text and rfc822 format available.

Message #18 received at 55123-quiet@bugs.debian.org (full text, mbox):

From: Brian White <bcwhite@pobox.com>
To: Peter S Galbraith <GalbraithP@dfo-mpo.gc.ca>, Mitch Blevins <mblevin@debian.org>
Cc: 55123-quiet@bugs.debian.org
Subject: Re: I think /etc/init.d/powerfail shouldn't be a conffile
Date: Sat, 15 Jan 2000 09:20:38 -0500
> I maintain the ups-monitor powstatd and something occurred to me
> about /etc/init.d/powerfail.  The bpowerd, genpower and powstatd
> all have /etc/init.d/powerfail as a conffile.  When a user tries
> installing these packages to see which is best for his UPS, he
> might inadvertently use the powerfail script from another
> package.

That's true.  Perhaps a "preinst" message saying to be sure to accept
the new conffile (as is found in some other packages) would be a help.


> I'm submitting this as a bug against my own package as a log of
> the discussion, if any.  I'm probably going to remove
> /etc/init.d/powerfail as a conffile and put whatever configuration
> it can have in another conffile, like /etc/init.d/powstatd.
> I'll email you both the bug number as soon as I get it, should
> you want your comments logged there too.

I think policy requires that all files under /etc be listed as conffiles.


> Sounds good to me.  Or maybe if we all used the _same_
> /etc/init.d/powerfail file to make it even simpler for the local
> admins.  I know mine is probably very similar to yours, but
> genpower checks an extra status file (and we don't).

Newer genpower packages don't actually need to check this status
file any more.  I've just never removed it because, with something
like this, it's better to be safe than sorry.  I could remove it,
or with a tiny alteration, make it behave the same without the file
as it would without ever looking for that file.  (Currently, if it
can't find the file at "start", it runs as though it was "now".)

If we can agree on a good solution, perhaps we could move "powerfail"
to the "sysvinit" package instead.

                                          Brian
                                  ( bcwhite@pobox.com )

-------------------------------------------------------------------------------
    In theory, theory and practice are the same.  In practice, they're not.


Acknowledgement sent to Peter S Galbraith <GalbraithP@dfo-mpo.gc.ca>:
Extra info received and filed, but not forwarded. Full text and rfc822 format available.

Message #21 received at 55123-quiet@bugs.debian.org (full text, mbox):

From: Peter S Galbraith <GalbraithP@dfo-mpo.gc.ca>
To: Brian White <bcwhite@pobox.com>
Cc: Peter S Galbraith <GalbraithP@dfo-mpo.gc.ca>, Mitch Blevins <mblevin@debian.org>, 55123-quiet@bugs.debian.org
Subject: Re: I think /etc/init.d/powerfail shouldn't be a conffile
Date: Sat, 15 Jan 2000 11:11:11 -0500
Brian White wrote:

> >                               The bpowerd, genpower and powstatd
> > all have /etc/init.d/powerfail as a conffile.  When a user tries
> > installing these packages to see which is best for his UPS, he
> > might inadvertently use the powerfail script from another
> > package.
> 
> That's true.  Perhaps a "preinst" message saying to be sure to accept
> the new conffile (as is found in some other packages) would be a help.

That's one way.  But it requires more user input than if
powerfail isn't a conffile at all.  The user needs to answer a
question we already know the proper answer to.  I think we can do
better.
 
> >                          I'm probably going to remove
> > /etc/init.d/powerfail as a conffile and put whatever configuration
> > it can have in another conffile, like /etc/init.d/powstatd.
> 
> I think policy requires that all files under /etc be listed as conffiles.

Yes, but we can likely change this. powerfail is an inittab
invention and so doesn't fit the usual mold of a conffile.  We
can argue it should have been /sbin/powerfail instead of under /etc.

> > Sounds good to me.  Or maybe if we all used the _same_
> > /etc/init.d/powerfail file to make it even simpler for the local
> > admins.  I know mine is probably very similar to yours, but
> > genpower checks an extra status file (and we don't).
> 
> Newer genpower packages don't actually need to check this status
> file any more.

We'd still need a generic powerfail script that could check such
a status file, since an as-yet-unreleased ups-monitor might need
it.  I guess.

> If we can agree on a good solution, perhaps we could move "powerfail"
> to the "sysvinit" package instead.

Yes, I think so.

This is probably the cleanest solution, albeit it does remove
flexibility to future/other ups-monitor packages.  On the other
hand, removing conffile status makes the problem go away and
keeps flexibility in the hands of ups-monitor package
maintainers.  We could still on principle alone all decide to use
the exact same file, making it a tiny bit easier for users
comparing ups-monitor packages to decipher how they work by
removing inter-package variability (took me a while the first
time I looked at this).

If you both agree that removing conffile status could be better
than moving a common file to sysvinit (for flexibility), I
volunteer to draft a policy proposal and pass it around to you
for review and discussion.  Otherwise, we have to make sure all
our packages work with the same powerfail file (with the
possibility of using a status file) and convince the sysvinit
maintainer to include it.

Either way is better than status-quo, but I think I prefer simply
removing conffile status.

Thanks,

Peter


Acknowledgement sent to Brian White <bcwhite@pobox.com>:
Extra info received and filed, but not forwarded. Full text and rfc822 format available.

Message #24 received at 55123-quiet@bugs.debian.org (full text, mbox):

From: Brian White <bcwhite@pobox.com>
To: Peter S Galbraith <GalbraithP@dfo-mpo.gc.ca>
Cc: Mitch Blevins <mblevin@debian.org>, 55123-quiet@bugs.debian.org
Subject: Re: I think /etc/init.d/powerfail shouldn't be a conffile
Date: Sat, 15 Jan 2000 11:27:26 -0500
[Message part 1 (text/plain, inline)]
> > I think policy requires that all files under /etc be listed as conffiles.
> 
> Yes, but we can likely change this. powerfail is an inittab
> invention and so doesn't fit the usual mold of a conffile.  We
> can argue it should have been /sbin/powerfail instead of under /etc.

As it stands, powerfail (genpower version, at least) has some configurable
options in it like how long to wait before shutdown.  As you say,
these could be moved elsewhere, but I don't think it's necessary.


> > > Sounds good to me.  Or maybe if we all used the _same_
> > > /etc/init.d/powerfail file to make it even simpler for the local
> > > admins.  I know mine is probably very similar to yours, but
> > > genpower checks an extra status file (and we don't).
> >
> > Newer genpower packages don't actually need to check this status
> > file any more.
> 
> We'd still need a generic powerfail script that could check such
> a status file, since an as-yet-unreleased ups-monitor might need
> it.  I guess.

That shouldn't be necessary.  The stat-file was an old mechanism for
working around limitations in sysvinit.  Now that there is a standardized
method for passing this information, ups-monitors should be updated
to use it.


> > If we can agree on a good solution, perhaps we could move "powerfail"
> > to the "sysvinit" package instead.
> 
> Yes, I think so.
> 
> This is probably the cleanest solution, albeit it does remove
> flexibility to future/other ups-monitor packages.  On the other
> hand, removing conffile status makes the problem go away and
> keeps flexibility in the hands of ups-monitor package
> maintainers.  We could still on principle alone all decide to use
> the exact same file, making it a tiny bit easier for users
> comparing ups-monitor packages to decipher how they work by
> removing inter-package variability (took me a while the first
> time I looked at this).

I can't see any reason why it can't be standardized.  It's more of a
system thing than anything else.

I've attached the genpower "powerfail" I've finished modifying to not
use the ups status file.  What would need to be added to support your
packages?


Now, as long as we're discussing this...  There's another nagging problem
that might be nice to solve at the same time...

There is a race condition in genpower and maybe your packages as well.  It
isn't possible to pick a static implementation that will _guarantee_ a
clean shutdown on power-fail and clean startup on power-good.

The problem stems from the fact that different UPS systems have different
behavior when killing the inverter.  APC waits 60 seconds from the signal
and then shuts off.  I can't guarantee it will shut off, though, if power
were to resume during this 60 seconds, but I think it does.  Others may
not.  One UPS (don't know which one) will always kill the inverter, but
not the power.  Thus, if the power were to fail again after an inverter-kill,
the UPS won't supply power and the computer might as well have been plugged
directly in to the wall.

Some people suggest doing a reboot instead of a halt, but then the computer
could be half-way into a reboot when the UPS turns off.

To fix this, I think we need support from "init".  The best method would
probably be to have "halt" know that it was started because of a power
failure and, at the last moment, do a "reboot" instead if the power is
determined to have come back.  Can anybody see any holes in this?  A new
"check" parameter in /etc/init.d/ups-monitor might be sufficient: return
0 if the UPS wasn't the cause of the shutdown, 1 if it was and the power
is still down, or 2 if it was and the power has returned.


> If you both agree that removing conffile status could be better
> than moving a common file to sysvinit (for flexibility), I
> volunteer to draft a policy proposal and pass it around to you
> for review and discussion.  Otherwise, we have to make sure all
> our packages work with the same powerfail file (with the
> possibility of using a status file) and convince the sysvinit
> maintainer to include it.

My preference would be to come up with a common one and get it in to
the sysvinit package.

                                          Brian
                                  ( bcwhite@pobox.com )

-------------------------------------------------------------------------------
      Cherish your yesterdays, dream your tomorrows, but live your todays.
[powerfail.rc (text/plain, inline)]
#! /bin/sh
#
# powerfail	This script is run when the UPS tells the system the power has
#		gone. Tell everybody and start the shutdown based on the failure
#		type.  This script will also being run when the power comes up
#		again.
#
# Version:	/etc/init.d/powerfail (v2.0)
#
# Authors:	Brian White <bcwhite@pobox.com>
#		Peter S Galbraith <GalbraithP@dfo-mpo.gc.ca>
#		Mitch Blevins <mblevin@debian.org>
#



failtime=+5	# shutdown delay from initial power failure
btrytime=now	# shutdown delay from low-battery warning

failmsg="LINE POWER FAILURE -- SWITCHED TO BATTERY BACKUP"
btrymsg="BACKUP BATTERY LOW -- EMERGENCY SHUTDOWN"
okaymsg="LINE POWER RESTORED -- RESUMING NORMAL OPERATION"

sdnotify=15	# maximum time shutdown that sends notices



# Set the path.
PATH=/sbin:/etc:/bin:/usr/bin

# Set location of file containing PID of running shutdowns
spidpath="/var/run/shutdown.pid"



# See what happened.
case "$1" in

    start)
	# Called with a powerfail event, check to see if a shutdown is running
	if [ -f $spidpath ]
	then
	    # Shutdown is running, kill it to process the new event
	    shutdown -c >/dev/null 2>&1
	fi

	if [ "$btrytime" != "now" ]; then
	    if [ `echo $btrytime | sed -e 's/[^0-9]//g'` -gt "$sdnotify" ]; then
		echo "$failmsg" | wall
	    fi
	fi

	shutdown -h $failtime "$failmsg" &


    now)
	# Called with a powerfail event, check to see if a shutdown is running
	if [ -f $spidpath ]
	then
	    # Shutdown is running, kill it to process the new event
	    shutdown -c >/dev/null 2>&1
	fi

	# Power is going down _now_
	shutdown -h $btrytime "$btrymsg" &
	;;


    stop)
	# Ok, power is good again. Say so on the console.
	if [ -f $spidpath ]
	then
	    # Only cancel if shutdown is running (system boot will call this)
	    shutdown -c "$okaymsg"
	fi
	;;


    *)
	echo "Usage: /etc/init.d/powerfail {start|now|stop}"
	exit 1
	;;

esac


exit 0

Acknowledgement sent to Mitch Blevins <mblevin@debian.org>:
Extra info received and filed, but not forwarded. Full text and rfc822 format available.

Message #27 received at 55123-quiet@bugs.debian.org (full text, mbox):

From: Mitch Blevins <mblevin@debian.org>
To: Brian White <bcwhite@pobox.com>
Cc: 55123-quiet@bugs.debian.org, GalbraithP@dfo-mpo.gc.ca
Subject: Re: I think /etc/init.d/powerfail shouldn't be a conffile
Date: Sat, 15 Jan 2000 13:56:56 -0500
Brian White wrote:
> > > I think policy requires that all files under /etc be listed as conffiles.
> > 
> > Yes, but we can likely change this. powerfail is an inittab
> > invention and so doesn't fit the usual mold of a conffile.  We
> > can argue it should have been /sbin/powerfail instead of under /etc.
> 
> As it stands, powerfail (genpower version, at least) has some configurable
> options in it like how long to wait before shutdown.  As you say,
> these could be moved elsewhere, but I don't think it's necessary.

After thinking about it, I don't think the answer is to make
/etc/init.d/powerfail a non-conffile.
There may be other options that the local administrator wants to
take on powerfail that cannot be cleanly supported by simply
sourcing a separate configuration file.  For example, the local admin
might want to page or email himself on a power loss.

However, having the /etc/init.d/powerfail as a conffile in the sysvinit
package is worthwhile if we can come up with a nice way to transition
to it.

> I've attached the genpower "powerfail" I've finished modifying to not
> use the ups status file.  What would need to be added to support your
> packages?

Works for me.

> Now, as long as we're discussing this...  There's another nagging problem
> that might be nice to solve at the same time...
> 
> There is a race condition...
> [snip]

To summarize, the problem only occurs for a broken UPS that will not
respect an inverter signal if the power comes back on, and only if
the power returns between the time "shutdown -h now" is called and
the actual reboot by init.  Is this right?

You suggest fixing this by providing an interface for init to call
that will tell if the power has returned that init will call at
the-last-second(tm).  But the-last-second occurs after the filesystem
has been unmounted, so a script interface is impossible.  You could
possibly shorten the time period for the race, but not eliminate it
without some other approach.

Am I missing something?

-Mitch



Acknowledgement sent to Peter S Galbraith <GalbraithP@dfo-mpo.gc.ca>:
Extra info received and filed, but not forwarded. Full text and rfc822 format available.

Message #30 received at 55123-quiet@bugs.debian.org (full text, mbox):

From: Peter S Galbraith <GalbraithP@dfo-mpo.gc.ca>
To: Mitch Blevins <mblevin@debian.org>, Brian White <bcwhite@pobox.com>
Cc: 55123-quiet@bugs.debian.org, GalbraithP@dfo-mpo.gc.ca
Subject: Re: I think /etc/init.d/powerfail shouldn't be a conffile
Date: Sat, 15 Jan 2000 16:40:08 -0500
Mitch Blevins wrote:

> After thinking about it, I don't think the answer is to make
> /etc/init.d/powerfail a non-conffile.
> There may be other options that the local administrator wants to
> take on powerfail that cannot be cleanly supported by simply
> sourcing a separate configuration file.  For example, the local admin
> might want to page or email himself on a power loss.

Okay, you have both convinced me.  Then the only solution is to
move to a single file in sysvinit.
 
> However, having the /etc/init.d/powerfail as a conffile in the sysvinit
> package is worthwhile if we can come up with a nice way to transition
> to it.

New sysvinit could conflict with current and lower versions of
our packages.  Our new packages could depends on new version of
sysvinit.

> > I've attached the genpower "powerfail" I've finished modifying to not
> > use the ups status file.  What would need to be added to support your
> > packages?
> 
> Works for me.

I'll get back to you.  Mine was simple, so probably okay.

> > Now, as long as we're discussing this...  There's another nagging problem
> > that might be nice to solve at the same time...
> > 
> > There is a race condition...
> > [snip]
> 
> To summarize, the problem only occurs for a broken UPS that will not
> respect an inverter signal if the power comes back on, and only if
> the power returns between the time "shutdown -h now" is called and
> the actual reboot by init.  Is this right?

Almost.  Unless I'm forgetting something, the system is
shutdown by "shutdown -h now" only on low battery.  This is a
technicality.  The race condition is usually between when the
shutdown time is reached from `shutdown -h $failtime "$failmsg"`
after $failtime, and the actual halt.  If power is returned then,
the UPS will not be cycled off/on and the system will stay in a
halted state.

I had initial thoughts about this.  See bug 47454 at
http://www.debian.org/Bugs/db/47/47454.html

I thought of working around it with a state file to know when
halt was called in case of power failure and check the status
again.  I can do that with powstatd because it returns FAIL when
I try the kill the inverter and the power is back on.

> You suggest fixing this by providing an interface for init to call
> that will tell if the power has returned that init will call at
> the-last-second(tm).  But the-last-second occurs after the filesystem
> has been unmounted, so a script interface is impossible.  You could
> possibly shorten the time period for the race, but not eliminate it
> without some other approach.

The root filesystem is still mounted, right?
 
> Am I missing something?

Am I?

Peter


Acknowledgement sent to Peter S Galbraith <GalbraithP@dfo-mpo.gc.ca>:
Extra info received and filed, but not forwarded. Full text and rfc822 format available.

Message #33 received at 55123-quiet@bugs.debian.org (full text, mbox):

From: Peter S Galbraith <GalbraithP@dfo-mpo.gc.ca>
To: Brian White <bcwhite@pobox.com>
Cc: Peter S Galbraith <GalbraithP@dfo-mpo.gc.ca>, Mitch Blevins <mblevin@debian.org>, 55123-quiet@bugs.debian.org
Subject: Re: I think /etc/init.d/powerfail shouldn't be a conffile
Date: Sat, 15 Jan 2000 20:06:53 -0500
Brian White wrote:

> I've attached the genpower "powerfail" I've finished modifying to not
> use the ups status file.  What would need to be added to support your
> packages?

It's equivalent to powstatd's version, except:

 - I tend not use all caps for messages.  But I agree it's important
   enough to do so.

 - I changed $btrytime and $btrymsg to $lowtime and $lowmsg so I
   could remember what they meant.

 - I didn't have the $sdnotify bit:

  if [ "$btrytime" != "now" ]; then
      if [ `echo $btrytime | sed -e 's/[^0-9]//g'` -gt "$sdnotify" ]; then
          echo "$failmsg" | wall
      fi
  fi

   Perhaps I'm missing somthing, but shouldn't you be comparing
   $failtime to $sdnotify instead of $btrytime (low battery
   shutdown time)?

 - I found the arguments to this script so unintuitive that I
   added them to the usage bit:

    *)
        echo "Usage: /etc/init.d/powerfail {start|now|stop}"
        echo " start means: shutdown in $failtime minutes due to power failure"
        echo " now means: shutdown NOW due to eminent UPS battery failure"
        echo " stop means: cancel shutdown because power is back online."
        exit 1

Also, my fix around the race condition bug mentioned involved changing
this script to create a status file (so we can tell shutdown was
called before of a power failure).  If you can get that done by
changing inittab behaviour instead, then great.  Can you?  hat that
your thinking?

Peter



Acknowledgement sent to Peter S Galbraith <GalbraithP@dfo-mpo.gc.ca>:
Extra info received and filed, but not forwarded. Full text and rfc822 format available.

Message #36 received at 55123-quiet@bugs.debian.org (full text, mbox):

From: Peter S Galbraith <GalbraithP@dfo-mpo.gc.ca>
To: Brian White <bcwhite@pobox.com>
Cc: Peter S Galbraith <GalbraithP@dfo-mpo.gc.ca>, Mitch Blevins <mblevin@debian.org>, 55123-quiet@bugs.debian.org
Subject: Re: I think /etc/init.d/powerfail shouldn't be a conffile
Date: Sun, 16 Jan 2000 10:38:16 -0500
I wrote typos:

> Also, my fix around the race condition bug mentioned involved changing
                                                      ^above

> this script to create a status file (so we can tell shutdown was
> called before of a power failure).  If you can get that done by
         ^^^^^^
`because'

> changing inittab behaviour instead, then great.  Can you?  hat that
                                                             ^^^
`was'
> your thinking?
> 
> Peter


Acknowledgement sent to Brian White <bcwhite@pobox.com>:
Extra info received and filed, but not forwarded. Full text and rfc822 format available.

Message #39 received at 55123-quiet@bugs.debian.org (full text, mbox):

From: Brian White <bcwhite@pobox.com>
To: Peter S Galbraith <GalbraithP@dfo-mpo.gc.ca>
Cc: Mitch Blevins <mblevin@debian.org>, 55123-quiet@bugs.debian.org
Subject: Re: I think /etc/init.d/powerfail shouldn't be a conffile
Date: Sun, 16 Jan 2000 11:54:37 -0500
[Message part 1 (text/plain, inline)]
>  - I didn't have the $sdnotify bit:
> 
>   if [ "$btrytime" != "now" ]; then
>       if [ `echo $btrytime | sed -e 's/[^0-9]//g'` -gt "$sdnotify" ]; then
>           echo "$failmsg" | wall
>       fi
>   fi
> 
>    Perhaps I'm missing somthing, but shouldn't you be comparing
>    $failtime to $sdnotify instead of $btrytime (low battery
>    shutdown time)?

You're absolutely correct!  I wonder how long that little buglet has
been around.


>  - I found the arguments to this script so unintuitive that I
>    added them to the usage bit:
> 
>     *)
>         echo "Usage: /etc/init.d/powerfail {start|now|stop}"
>         echo " start means: shutdown in $failtime minutes due to power failure"
>         echo " now means: shutdown NOW due to eminent UPS battery failure"
>         echo " stop means: cancel shutdown because power is back online."
>         exit 1

That's a good idea.  I can't see why anything but init would be calling
this, but it's different than most init.d scripts, so this could be
useful.


> To summarize, the problem only occurs for a broken UPS that will not
> respect an inverter signal if the power comes back on, and only if
> the power returns between the time "shutdown -h now" is called and
> the actual reboot by init.  Is this right?

That's one possible problem.  The more common one is a UPS that won't
kill the power at all if line power is on.  If line power were to return,
as Peter said, between the instant that the shutdown begins and the
time the "halt" script is called, the UPS wouldn't power down and your
machine would be stuck saying "system halted".

Even with my suggestion, there is still a race condition should the
power return between the "check" and the "poweroff" calls, but at
least this should only be a few hundred milliseconds instead of
several seconds.


> You suggest fixing this by providing an interface for init to call
> that will tell if the power has returned that init will call at
> the-last-second(tm).  But the-last-second occurs after the filesystem
> has been unmounted, so a script interface is impossible.  You could
> possibly shorten the time period for the race, but not eliminate it
> without some other approach.

The root filesystem not actually unmounted, but rather remounted read-only.
Thanks for pointing this out, though.  I was thinking of keeping the
"ups-status" file (see below) under /var/run because that is cleaned by
the system boot, but it's possible that /var won't be mounted.  /etc
always will, though.  That means adding a "rm -f $upspath" in
"ups-monitor start", though.  Oh well.


> Also, my fix around the race condition bug mentioned involved changing
> this script to create a status file (so we can tell shutdown was
> called before of a power failure).  If you can get that done by
> changing inittab behaviour instead, then great.  Can you?  hat that
> your thinking?

I've attached updated "powerfail" and "ups-monitor" (genpower version)
scripts that I think will do this.

Basicly, the new "powerfail" script writes a code to /etc/ups-status
which is checked by "ups-monitor".  If the file doesn't exist, then
"ups-monitor" returns a code of 0.  If it does exist, then it calls
genpower with an option that merely checks the status of the UPS and
returns.  (Note that I still have to add this functionality to the
"genpowerd" program.)

I've also attached a version of "/etc/init.d/halt" that I think will
use this appropriately.

                                          Brian
                                  ( bcwhite@pobox.com )

-------------------------------------------------------------------------------
     The power to shape the future is earned through persistence.  No other
      quality is as essential to success.  It is the sandpaper that breaks
     down all resistance and sweeps away all abstacles.  It is the ability
                 to move mountains one grain of sand at a time.
[powerfail.rc (text/plain, inline)]
#! /bin/sh
#
# powerfail	This script is run when the UPS tells the system the power has
#		gone. Tell everybody and start the shutdown based on the failure
#		type.  This script will also being run when the power comes up
#		again.
#
# Version:	/etc/init.d/powerfail (v2.0)
#
# Authors:	Brian White <bcwhite@pobox.com>
#		Peter S Galbraith <GalbraithP@dfo-mpo.gc.ca>
#		Mitch Blevins <mblevin@debian.org>
#



failtime=+5	# shutdown delay from initial power failure
btrytime=now	# shutdown delay from low-battery warning

failmsg="LINE POWER FAILURE -- SWITCHED TO BATTERY BACKUP"
btrymsg="BACKUP BATTERY LOW -- EMERGENCY SHUTDOWN"
okaymsg="LINE POWER RESTORED -- RESUMING NORMAL OPERATION"

sdnotify=15	# maximum time shutdown that sends notices



# Set the path.
PATH=/sbin:/etc:/bin:/usr/bin

# Set location of file containing PID of running shutdowns
spidpath=/var/run/shutdown.pid

# Set location of UPS status
upspath=/var/run/ups-status



# See what happened.
case "$1" in


    start)
	# Called with a powerfail event, check to see if a shutdown is running
	if [ -f $spidpath ]
	then
	    # Shutdown is running, kill it to process the new event
	    shutdown -c >/dev/null 2>&1
	fi

	if [ "$failtime" != "now" ]; then
	    if [ `echo $failtime | sed -e 's/[^0-9]//g'` -gt "$sdnotify" ]; then
		echo "$failmsg" | wall
	    fi
	fi

	shutdown -h $failtime "$failmsg" &
	echo "fail" >$upspath
	;;


    now)
	# Called with a powerfail event, check to see if a shutdown is running
	if [ -f $spidpath ]
	then
	    # Shutdown is running, kill it to process the new event
	    shutdown -c >/dev/null 2>&1
	fi

	# Power is going down _now_
	shutdown -h $btrytime "$btrymsg" &
	echo "now" >$upspath
	;;


    stop)
	# Ok, power is good again. Say so on the console.
	if [ -f $spidpath ]
	then
	    # Only cancel if shutdown is running (system boot will call this)
	    shutdown -c "$okaymsg"
	fi
	rm -f $upspath
	;;


    *)
	echo "Usage: /etc/init.d/powerfail {start|now|stop}"
	echo " start: shutdown in $failtime minutes due to power failure"
	echo " now:   shutdown NOW due to eminent UPS battery failure"
	echo " stop:  cancel shutdown because power is back online"
	echo " (note that this script is usually called only by 'init')"
	exit 1
	;;


esac


exit 0
[genpower.rc (text/plain, inline)]
#! /bin/sh
#
# genpower	This script is used to start the UPS management daemon.	 When
#		called with "poweroff", this script will attempt to shutdown
#		the UPS in order to preserve the battery.  This should only
#		be done when going to run-level 0 ("system halt").
#
# Version:	/etc/init.d/genpower
#
# Author:	Brian White <bcwhite@pobox.com>
#

enabled=0
upsport=/dev/ups
upstype=apc-pnp

genpowerd=/sbin/genpowerd
genwrite=/sbin/genwrite
upspath=/etc/ups-status
PATH=/usr/bin:/bin:/usr/sbin:/sbin


if [ ! -x $genpowerd ]
then
    exit 0
fi

if [ "$enabled" = 0 ]
then
    echo "/etc/init.d/genpower: UPS monitor daemon not enabled"
    exit 0
fi


#function setdumbsignal {
#    if [ "$1" = "apc-pnp" ]; then
#	echo -n "(switch to dumb-signalling mode) "
#	$genwrite -d $upsport "R"
#    fi
#}


case "$1" in

    start)
	echo -n "Starting UPS monitor: genpowerd "
	killall genpowerd >/dev/null 2>&1
#	setdumbsignal $upstype
	rm -f $upspath
	$genpowerd $upsport $upstype
	echo "."
	;;

    stop)
	echo -n "Stopping UPS monitor: genpowerd "
	killall genpowerd >/dev/null 2>&1
	echo "."
	;;

    poweroff)
	echo "Sending power-down signal to the UPS..."
	sync; sync; sleep 2
	$genpowerd -k $upsport $upstype >/dev/null 2>&1
	;;


    check)
	if [ ! -r $upspath ]; then
	    exit 0
	fi
	if $genpowerd -c $upsport $upstype >/dev/null 2>&1; then
	    exit 2
	fi
	exit 1
	;;


    *)
	echo "Usage: /etc/init.d/genpower {start|stop|poweroff|check}"
	exit 1
	;;

esac


exit 0
[halt.rc (text/plain, inline)]
#! /bin/sh
#
# halt		Execute the halt command.
#
# Version:      @(#)halt  2.75  19-May-1998  miquels@cistron.nl
#

PATH=/sbin:/bin:/usr/sbin:/usr/bin
halt="halt -d -f -i -p"
boot="reboot -d -f -i"

# check the status of the line power
if [ -x /etc/init.d/ups-monitor ]
then
	/etc/init.d/ups-monitor check
	case "$?" in

	0)
	    # ups wasn't the cause of the shutdown -- do nothing
	    ;;
	
	1)
	    echo "Line power failure -- halting..."
	    /etc/init.d/ups-monitor poweroff
	    $halt
	    ;;

	2)
	    echo "Line power restored -- rebooting..."
	    $boot
	    ;;

	esac
fi

echo "Halting..."
$halt

Acknowledgement sent to Peter S Galbraith <GalbraithP@dfo-mpo.gc.ca>:
Extra info received and filed, but not forwarded. Full text and rfc822 format available.

Message #42 received at 55123-quiet@bugs.debian.org (full text, mbox):

From: Peter S Galbraith <GalbraithP@dfo-mpo.gc.ca>
To: Brian White <bcwhite@pobox.com>
Cc: Peter S Galbraith <GalbraithP@dfo-mpo.gc.ca>, Mitch Blevins <mblevin@debian.org>, 55123-quiet@bugs.debian.org
Subject: Re: I think /etc/init.d/powerfail shouldn't be a conffile
Date: Sun, 16 Jan 2000 16:49:02 -0500
Brian White wrote:

>                               The more common one is a UPS that won't
> kill the power at all if line power is on.  

Right.  Standard behaviour on CyberPower UPSes.

>                                             If line power were to return,
> as Peter said, between the instant that the shutdown begins and the
> time the "halt" script is called, the UPS wouldn't power down and your
> machine would be stuck saying "system halted".

> I've attached updated "powerfail" and "ups-monitor" (genpower version)
> scripts that I think will do this.

The status file is pretty much like I wanted to do it for
powtstad as far as the powerfail script (See
debian/*with-state-file in powtstad source .diif.gz file).
Here's what I had converning that file (In my case, it only
exists if we are on power failure status):

powerfail:
    start)
        touch $statpath
    now)
        touch $statpath
    stop)
        rm -f $statpath
 

ups-monitor:
  start)
    rm -f $statpath
  poweroff)
    if [ -f $statpath ]
    then
        rm -f $statpath
        $DAEMON -k > /dev/null 2>&1
    fi
  force-reload|restart)
    rm -f $statpath

> Basicly, the new "powerfail" script writes a code to /etc/ups-status
> which is checked by "ups-monitor".  If the file doesn't exist, then
> "ups-monitor" returns a code of 0.  If it does exist, then it calls
> genpower with an option that merely checks the status of the UPS and
> returns.  (Note that I still have to add this functionality to the
> "genpowerd" program.)

powstatd also doesn't have a `--check' option.  I wonder if
forcing ups monitors to have such a thing is too much to ask?
In my case, I could even work around it without touching the
code.

`powstatd -k` returns FAIL if it failed to kill the UPS because
power is on.  On `/etc/init.d/ups-monitor check` I could simply

 1- check for the status file.
 2- if it exists try to kill the UPS now.
 3- if I fail, return "2"
 4- if I succeed, return "1" and do nothing later with argument "poweroff"

Kinda perserve, but it would work.

Peter


Acknowledgement sent to Peter S Galbraith <GalbraithP@dfo-mpo.gc.ca>:
Extra info received and filed, but not forwarded. Full text and rfc822 format available.

Message #45 received at 55123-quiet@bugs.debian.org (full text, mbox):

From: Peter S Galbraith <GalbraithP@dfo-mpo.gc.ca>
To: Brian White <bcwhite@pobox.com>
Cc: Peter S Galbraith <GalbraithP@dfo-mpo.gc.ca>, Mitch Blevins <mblevin@debian.org>, 55123-quiet@bugs.debian.org
Subject: Re: I think /etc/init.d/powerfail shouldn't be a conffile
Date: Sun, 16 Jan 2000 20:53:08 -0500
I think the proposed new /etc/init.d/halt script should still support
ups-monitors that don't have support for a power line check by at least
behaving the same way it used to (by calling halt).  Something like:

#! /bin/sh
#
# halt		Execute the halt command.
#
# Version:      @(#)halt  2.75  19-May-1998  miquels@cistron.nl
#

PATH=/sbin:/bin:/usr/sbin:/usr/bin
halt="halt -d -f -i -p"
boot="reboot -d -f -i"

# check the status of the line power
if [ -x /etc/init.d/ups-monitor ]
then
        # Have your ups-monitor script return 0 if it can't check power line
        # status, halt will be called as usual.
	/etc/init.d/ups-monitor check
	case "$?" in

	0)
            # No info on power line status, halt and hope.
	    /etc/init.d/ups-monitor poweroff
	    $halt
	    ;;

	1)
	    # ups wasn't the cause of the shutdown -- do nothing
	    ;;
	
	2)
	    echo "Line power failure -- halting..."
	    /etc/init.d/ups-monitor poweroff
	    $halt
	    ;;

	3)
	    echo "Line power restored -- rebooting..."
	    $boot
	    ;;

	esac
fi

echo "Halting..."
$halt


But, to tell the truth, I wonder why the extra `check' step is really
required.  It could be combined with poweroff (kill the UPS):

#! /bin/sh
#
# halt          Execute the halt command.
#
# Version:      @(#)halt  2.75  19-May-1998  miquels@cistron.nl
#
 
PATH=/sbin:/bin:/usr/sbin:/usr/bin
halt="halt -d -f -i -p"
boot="reboot -d -f -i"

# check the status of the line power
if [ -x /etc/init.d/ups-monitor ]
then
        # Have your ups-monitor script return:
        #  0 if power failure wasn't the cause of the shutdown
        #  1 if power failure was the cause of the shutdown and the
        #    ups-monitor script sent the kill signal to the UPS but has no
        #    knowledge of whether the power has been restored.
        #  2 if power failure was the cause of the shutdown and the
        #    ups-monitor script sent the kill signal to the UPS and
        #    confirms power failure persists and kill signal was accepted.
        #  3 if power failure was the cause of the shutdown, but
        #    ups-monitor detects power has returned and we should reboot
        #    instead of halting the system

        /etc/init.d/ups-monitor poweroff
        case "$?" in

        0) 
            # ups wasn't the cause of the shutdown -- do nothing
            ;;

        1)
            # No info on power line status, halt and hope.
            echo "Line power failure -- halting..."
            $halt
            ;;

        2)
            # Confirmed power failure persists; UPS killed.
            echo "Line power failure -- halting..."
            $halt
            ;;   

        3)
            echo "Line power restored -- rebooting..."
            $boot
            ;;   

        esac
fi

echo "Halting..."
$halt



This last script makes the shutdown process a bit easier to follow and
understand because there is one less exchange between scripts.  Also, a
ups-monitor program that doesn't have power check capability can simply use
a ups-monitor script that returns 1 and compatibilty is maintained.  Since
returns codes 1 and 2 end up doing the same thing, they could be combined.
I could setup powstatd with the above script without having to add `power
check' capability (because the only time we really need to know, we want to
kill the UPS anyway if power is off).

Now, at this point, we had included in the discussion only the 3 packages
that used the powerfail script.  Since now we are talking of modifying the
halt script (and what it expects from the ups-monitor script), we should
probably include maintainers of all ups packages that have a ups-monitor
script.  Strangely, I only get powstatd and genpower by grepping through
potato/Contents-i386.gz.  Are the others not using it, or are they creating
the link in postinst? I checked upsd and it doesn't seem to use it.
Strange.  Maybe we have nothing to worry about concerning them.


Peter


Acknowledgement sent to Brian White <bcwhite@pobox.com>:
Extra info received and filed, but not forwarded. Full text and rfc822 format available.

Message #48 received at 55123-quiet@bugs.debian.org (full text, mbox):

From: Brian White <bcwhite@pobox.com>
To: Peter S Galbraith <GalbraithP@dfo-mpo.gc.ca>
Cc: Mitch Blevins <mblevin@debian.org>, 55123-quiet@bugs.debian.org
Subject: Re: I think /etc/init.d/powerfail shouldn't be a conffile
Date: Tue, 18 Jan 2000 07:04:23 -0500
[Message part 1 (text/plain, inline)]
> >                                             If line power were to return,
> > as Peter said, between the instant that the shutdown begins and the
> > time the "halt" script is called, the UPS wouldn't power down and your
> > machine would be stuck saying "system halted".
> 
> > I've attached updated "powerfail" and "ups-monitor" (genpower version)
> > scripts that I think will do this.
> 
> The status file is pretty much like I wanted to do it for
> powtstad as far as the powerfail script (See
> debian/*with-state-file in powtstad source .diif.gz file).
> Here's what I had converning that file (In my case, it only
> exists if we are on power failure status):

That seems almost the same.  The only difference I can see is that I
wrote a word stating "fail" or "now".


> > Basicly, the new "powerfail" script writes a code to /etc/ups-status
> > which is checked by "ups-monitor".  If the file doesn't exist, then
> > "ups-monitor" returns a code of 0.  If it does exist, then it calls
> > genpower with an option that merely checks the status of the UPS and
> > returns.  (Note that I still have to add this functionality to the
> > "genpowerd" program.)
> 
> powstatd also doesn't have a `--check' option.  I wonder if
> forcing ups monitors to have such a thing is too much to ask?
> In my case, I could even work around it without touching the
> code.
> 
> `powstatd -k` returns FAIL if it failed to kill the UPS because
> power is on.  On `/etc/init.d/ups-monitor check` I could simply

That's a good idea!  No need to have a separate function that I can
see.

I've updated "halt" and "ups-monitor" to run this way.  "halt" now
expects "ups-monitor poweroff" to return true if the power is still
down (halt machine) or false if power is back (reboot machine).

This also means that "ups-monitor check" now only has to return
true of false.  The return code of 2 is no longer needed.

Note that some UPS monitors may never return as some UPS systems
have to be monitored right up until the UPS shuts off.  The system
is fully clean at this point, so not calling the actual "halt" binary
isn't a problem.


Now that I read your next mail, it seems we're both thinking the same
way on this.

When dealing with a UPS that won't detect if line power has returned, I
guess we'll just have to hope that it will, at the very least, shut off
and turn back on.  I don't see how anything we can do will improve upon
this situation.


I think the next step, once we all agree that the "halt", "powerfail",
and "ups-monitor" scripts do what the should, is to contact Miquel and
get his opinion.  I've dealt with him before (getting this stuff in to
the "halt" script originally) and he's really good about these things.

                                          Brian
                                  ( bcwhite@pobox.com )

-------------------------------------------------------------------------------
            We have enough youth.  How about a fountain of "smart"?
[powerfail.rc (text/plain, inline)]
#! /bin/sh
#
# powerfail	This script is run when the UPS tells the system the power has
#		gone. Tell everybody and start the shutdown based on the failure
#		type.  This script will also being run when the power comes up
#		again.
#
# Version:	/etc/init.d/powerfail (v2.0)
#
# Authors:	Brian White <bcwhite@pobox.com>
#		Peter S Galbraith <GalbraithP@dfo-mpo.gc.ca>
#		Mitch Blevins <mblevin@debian.org>
#



failtime=+5	# shutdown delay from initial power failure
btrytime=now	# shutdown delay from low-battery warning

failmsg="LINE POWER FAILURE -- SWITCHED TO BATTERY BACKUP"
btrymsg="BACKUP BATTERY LOW -- EMERGENCY SHUTDOWN"
okaymsg="LINE POWER RESTORED -- RESUMING NORMAL OPERATION"

sdnotify=15	# maximum time shutdown that sends notices



# Set the path.
PATH=/sbin:/etc:/bin:/usr/bin

# Set location of file containing PID of running shutdowns
spidpath=/var/run/shutdown.pid

# Set location of UPS status
upspath=/var/run/ups-status



# See what happened.
case "$1" in


    start)
	# Called with a powerfail event, check to see if a shutdown is running
	if [ -f $spidpath ]
	then
	    # Shutdown is running, kill it to process the new event
	    shutdown -c >/dev/null 2>&1
	fi

	if [ "$failtime" != "now" ]; then
	    if [ `echo $failtime | sed -e 's/[^0-9]//g'` -gt "$sdnotify" ]; then
		echo "$failmsg" | wall
	    fi
	fi

	shutdown -h $failtime "$failmsg" &
	echo "fail" >$upspath
	;;


    now)
	# Called with a powerfail event, check to see if a shutdown is running
	if [ -f $spidpath ]
	then
	    # Shutdown is running, kill it to process the new event
	    shutdown -c >/dev/null 2>&1
	fi

	# Power is going down _now_
	shutdown -h $btrytime "$btrymsg" &
	echo "now" >$upspath
	;;


    stop)
	# Ok, power is good again. Say so on the console.
	if [ -f $spidpath ]
	then
	    # Only cancel if shutdown is running (system boot will call this)
	    shutdown -c "$okaymsg"
	fi
	rm -f $upspath
	;;


    *)
	echo "Usage: /etc/init.d/powerfail {start|now|stop}"
	echo " start: shutdown in $failtime minutes due to power failure"
	echo " now:   shutdown NOW due to eminent UPS battery failure"
	echo " stop:  cancel shutdown because power is back online"
	echo " (note that this script is usually called only by 'init')"
	exit 1
	;;


esac


exit 0
[genpower.rc (text/plain, inline)]
#! /bin/sh
#
# genpower	This script is used to start the UPS management daemon.	 When
#		called with "poweroff", this script will attempt to shutdown
#		the UPS in order to preserve the battery.  This should only
#		be done when going to run-level 0 ("system halt").
#
# Version:	/etc/init.d/genpower
#
# Author:	Brian White <bcwhite@pobox.com>
#

enabled=0
upsport=/dev/ups
upstype=apc-pnp

genpowerd=/sbin/genpowerd
genwrite=/sbin/genwrite
upspath=/etc/ups-status
PATH=/usr/bin:/bin:/usr/sbin:/sbin


if [ ! -x $genpowerd ]
then
    exit 0
fi

if [ "$enabled" = 0 ]
then
    echo "/etc/init.d/genpower: UPS monitor daemon not enabled"
    exit 0
fi


#function setdumbsignal {
#    if [ "$1" = "apc-pnp" ]; then
#	echo -n "(switch to dumb-signalling mode) "
#	$genwrite -d $upsport "R"
#    fi
#}


case "$1" in

    start)
	echo -n "Starting UPS monitor: genpowerd "
	killall genpowerd >/dev/null 2>&1
#	setdumbsignal $upstype
	rm -f $upspath
	$genpowerd $upsport $upstype
	echo "."
	;;

    stop)
	echo -n "Stopping UPS monitor: genpowerd "
	killall genpowerd >/dev/null 2>&1
	echo "."
	;;

    poweroff)
	echo "Sending power-down signal to the UPS..."
	sync; sync; sleep 2
	$genpowerd -k $upsport $upstype >/dev/null 2>&1
	;;


    check)
	if [ ! -r $upspath ]; then
	    exit 0
	else
	    exit 1
	fi
	;;


    *)
	echo "Usage: /etc/init.d/genpower {start|stop|poweroff|check}"
	exit 1
	;;

esac


exit 0
[halt.rc (text/plain, inline)]
#! /bin/sh
#
# halt		Execute the halt command.
#
# Version:      @(#)halt  2.75  19-May-1998  miquels@cistron.nl
#

PATH=/sbin:/bin:/usr/sbin:/usr/bin
halt="halt -d -f -i -p"
boot="reboot -d -f -i"

# check the status of the line power
if [ -x /etc/init.d/ups-monitor ]; then

    if /etc/init.d/ups-monitor check; then

	# ups wasn't the cause of the shutdown -- do nothing

    else

	if /etc/init.d/ups-monitor poweroff; then
	    echo "Line power failure -- halting..."
	    $halt
	else
	    echo "Line power restored -- rebooting..."
	    $boot
	fi

    fi

fi

echo "Halting..."
$halt

Acknowledgement sent to Peter S Galbraith <GalbraithP@dfo-mpo.gc.ca>:
Extra info received and filed, but not forwarded. Full text and rfc822 format available.

Message #51 received at 55123-quiet@bugs.debian.org (full text, mbox):

From: Peter S Galbraith <GalbraithP@dfo-mpo.gc.ca>
To: Brian White <bcwhite@pobox.com>
Cc: Peter S Galbraith <GalbraithP@dfo-mpo.gc.ca>, Mitch Blevins <mblevin@debian.org>, 55123-quiet@bugs.debian.org
Subject: Re: I think /etc/init.d/powerfail shouldn't be a conffile
Date: Tue, 18 Jan 2000 10:15:16 -0500
Brian White wrote:

> That's a good idea!  No need to have a separate function that I can
> see.
> 
> I've updated "halt" and "ups-monitor" to run this way.  "halt" now
> expects "ups-monitor poweroff" to return true if the power is still
> down (halt machine) or false if power is back (reboot machine).
> 
> This also means that "ups-monitor check" now only has to return
> true of false.  The return code of 2 is no longer needed.

And all it does is check the presence if the status file.  Very clean.

> Now that I read your next mail, it seems we're both thinking the same
> way on this.

Yes, we are.  But I like your new version better.  It's easier to
follow, very clear.

> I think the next step, once we all agree that the "halt", "powerfail",
> and "ups-monitor" scripts do what the should, 

I haved _really_ tried the newest script with powstatd, but I see no
problem at all.  It's a much better scheme than we have now.

>                                               is to contact Miquel and
> get his opinion.  I've dealt with him before (getting this stuff in to
> the "halt" script originally) 

I always thought they came that way upstream.  Interesting!

>                               and he's really good about these things.

If he agrees, the next step will be for us all to create new
packages with the appropriate depends and conflicts, and either
upload them all at the same time or first test them out with the
new sysvinit package.

I'd like to request the smallest of changes:

# powerfail	This script is run when the UPS tells the system the power has
#		gone. Tell everybody and start the shutdown based on the failure
#		type.  This script will also being run when the power comes up
#		again.

to

# powerfail      This script is run when the UPS tells the system that the 
#                power has gone. Tell everybody and start the shutdown based
#                on the failure type.  This script will also run when the 
#                power comes up again.

(Small edits and wrap before 80th column).


Peter



Acknowledgement sent to Peter S Galbraith <GalbraithP@dfo-mpo.gc.ca>:
Extra info received and filed, but not forwarded. Full text and rfc822 format available.

Message #54 received at 55123-quiet@bugs.debian.org (full text, mbox):

From: Peter S Galbraith <GalbraithP@dfo-mpo.gc.ca>
To: Brian White <bcwhite@pobox.com>
Cc: Peter S Galbraith <GalbraithP@dfo-mpo.gc.ca>, Mitch Blevins <mblevin@debian.org>, 55123-quiet@bugs.debian.org
Subject: Simplifying halt script a tad more.
Date: Tue, 18 Jan 2000 13:02:37 -0500
BTW, you currently have upspath=/etc/ups-status in genpower.rc
and upspath=/var/run/ups-status in powerfail.rc !  Which do we use?

Peter


Acknowledgement sent to Peter S Galbraith <GalbraithP@dfo-mpo.gc.ca>:
Extra info received and filed, but not forwarded. Full text and rfc822 format available.

Message #57 received at 55123-quiet@bugs.debian.org (full text, mbox):

From: Peter S Galbraith <GalbraithP@dfo-mpo.gc.ca>
To: Brian White <bcwhite@pobox.com>
Cc: Peter S Galbraith <GalbraithP@dfo-mpo.gc.ca>, Mitch Blevins <mblevin@debian.org>, 55123-quiet@bugs.debian.org
Subject: Simplifying halt script a tad more
Date: Tue, 18 Jan 2000 13:38:14 -0500
Brain wrote:

> #! /bin/sh
> #
> # halt		Execute the halt command.
> #
> # Version:      @(#)halt  2.75  19-May-1998  miquels@cistron.nl
> #
> 
> PATH=/sbin:/bin:/usr/sbin:/usr/bin
> halt="halt -d -f -i -p"
> boot="reboot -d -f -i"
> 
> # check the status of the line power
> if [ -x /etc/init.d/ups-monitor ]; then
> 
>     if /etc/init.d/ups-monitor check; then
> 
>         # ups wasn't the cause of the shutdown -- do nothing
> 
>     else
> 
>         if /etc/init.d/ups-monitor poweroff; then
>             echo "Line power failure -- halting..."
>             $halt
>         else
>             echo "Line power restored -- rebooting..."
>             $boot
>         fi
> 
>     fi
> 
> fi
> 
> echo "Halting..."
> $halt

I wonder if we can simplify this even more.  The powerfail file
gets moved to sysvinit, so why have the halt script (another
sysvinit file) call an external package to check for a file
sysvinit created in the first place?

We could have:

--cut--
#! /bin/sh
#
# halt		Execute the halt command.
#
# Version:      @(#)halt  2.75  19-May-1998  miquels@cistron.nl
#

PATH=/sbin:/bin:/usr/sbin:/usr/bin
halt="halt -d -f -i -p"
boot="reboot -d -f -i"

# Set location of UPS status
upspath=/var/run/ups-status

# Is there a UPS monitoniring package installed?
if [ -x /etc/init.d/ups-monitor ]; then

    # Check the status of the line power
    if [ ! -r $upspath ]; then

        # ups wasn't the cause of the shutdown -- do nothing

    else

        if /etc/init.d/ups-monitor poweroff; then
            echo "Line power failure -- halting..."
            $halt
        else
            echo "Line power restored -- rebooting..."
            $boot
        fi

    fi

fi

echo "Halting..."
$halt
--cut--

With the above, ups-monitor packages that cannot detect if the
power came back on halt can simply always return EXIT_SUCCESS (0)
and the system will halt (as it used to before we proposed this
stuff).  Better packages return EXIT_FAILURE (1) when the power
has indeed returned and a reboot is requested (This is the same
as your version).

The only issue concerning $upspath that ups-monitor packages need
to address is to delete the $upspath file on daemon start.  The
`check' argument is no longer used; it's all done by the sysvinit
package.

What do you think?

Peter


Acknowledgement sent to Peter S Galbraith <GalbraithP@dfo-mpo.gc.ca>:
Extra info received and filed, but not forwarded. Full text and rfc822 format available.

Message #60 received at 55123-quiet@bugs.debian.org (full text, mbox):

From: Peter S Galbraith <GalbraithP@dfo-mpo.gc.ca>
To: Brian White <bcwhite@pobox.com>
Cc: Peter S Galbraith <GalbraithP@dfo-mpo.gc.ca>, Mitch Blevins <mblevin@debian.org>, 55123-quiet@bugs.debian.org
Subject: Simplifying halt script a tad more
Date: Tue, 18 Jan 2000 15:05:05 -0500
[Message part 1 (text/plain, inline)]
I had a syntax error running the proposed halt script near the
empty `if' `else' contruct, so I changed it to simply:

  # Is there a UPS monitoniring package installed?
  if [ -x /etc/init.d/ups-monitor ]; then
  
      # Check the status of the line power.
      # Do nothing here if ups wasn't the cause of the shutdown.
      if [ -r $upspath ]; then
  
          if /etc/init.d/ups-monitor poweroff; then
              echo "Line power failure -- halting..."
              $halt
          else
              echo "Line power restored -- rebooting..."
              $boot
          fi
  
      fi
  
  fi

I have built a powstatd package and tested it with the attached
proposed powerfail and halt scripts (I also included the powstatd
ups-monitor script).  In one test, I plugged the power cord back
in after the halt sequence had begun. It was _nice_ to see the
machine reboot at the end when the condition was detected!

The hung state I can still get in now is when the power returns
_after_ I have sent the kill signal to the UPS and have halted
the system.  The UPS shuts down, but since the power is back
there is nothing to tell it to turn back on.  At least that's a
30 second window;  smaller than it used to be.

Peter

[halt (text/plain, inline)]
#! /bin/sh
#
# halt		Execute the halt command.
#
# Version:      @(#)halt  2.75  19-May-1998  miquels@cistron.nl
#

PATH=/sbin:/bin:/usr/sbin:/usr/bin
halt="halt -d -f -i -p"
boot="reboot -d -f -i"

# Set location of UPS status
upspath=/var/run/ups-status

# Is there a UPS monitoniring package installed?
if [ -x /etc/init.d/ups-monitor ]; then

    # Check the status of the line power.
    # Do nothing here if ups wasn't the cause of the shutdown.
    if [ -r $upspath ]; then

        if /etc/init.d/ups-monitor poweroff; then
            echo "Line power failure -- halting..."
            $halt
        else
            echo "Line power restored -- rebooting..."
            $boot
        fi

    fi

fi

echo "Halting..."
$halt
[powerfail (text/plain, inline)]
#! /bin/sh
#
# powerfail	This script is run when the UPS tells the system the power has
#		gone. Tell everybody and start the shutdown based on the failure
#		type.  This script will also being run when the power comes up
#		again.
#
# Version:	/etc/init.d/powerfail (v2.0)
#
# Authors:	Brian White <bcwhite@pobox.com>
#		Peter S Galbraith <GalbraithP@dfo-mpo.gc.ca>
#		Mitch Blevins <mblevin@debian.org>
#



failtime=+1	# shutdown delay from initial power failure
btrytime=now	# shutdown delay from low-battery warning

failmsg="LINE POWER FAILURE -- SWITCHED TO BATTERY BACKUP"
btrymsg="BACKUP BATTERY LOW -- EMERGENCY SHUTDOWN"
okaymsg="LINE POWER RESTORED -- RESUMING NORMAL OPERATION"

sdnotify=15	# maximum time shutdown that sends notices



# Set the path.
PATH=/sbin:/etc:/bin:/usr/bin

# Set location of file containing PID of running shutdowns
spidpath=/var/run/shutdown.pid

# Set location of UPS status
upspath=/var/run/ups-status



# See what happened.
case "$1" in


    start)
	# Called with a powerfail event, check to see if a shutdown is running
	if [ -f $spidpath ]
	then
	    # Shutdown is running, kill it to process the new event
	    shutdown -c >/dev/null 2>&1
	fi

	if [ "$failtime" != "now" ]; then
	    if [ `echo $failtime | sed -e 's/[^0-9]//g'` -gt "$sdnotify" ]; then
		echo "$failmsg" | wall
	    fi
	fi

	shutdown -h $failtime "$failmsg" &
	echo "fail" >$upspath
	;;


    now)
	# Called with a powerfail event, check to see if a shutdown is running
	if [ -f $spidpath ]
	then
	    # Shutdown is running, kill it to process the new event
	    shutdown -c >/dev/null 2>&1
	fi

	# Power is going down _now_
	shutdown -h $btrytime "$btrymsg" &
	echo "now" >$upspath
	;;


    stop)
	# Ok, power is good again. Say so on the console.
	if [ -f $spidpath ]
	then
	    # Only cancel if shutdown is running (system boot will call this)
	    shutdown -c "$okaymsg"
	fi
	rm -f $upspath
	;;


    *)
	echo "Usage: /etc/init.d/powerfail {start|now|stop}"
	echo " start: shutdown in $failtime minutes due to power failure"
	echo " now:   shutdown NOW due to eminent UPS battery failure"
	echo " stop:  cancel shutdown because power is back online"
	echo " (note that this script is usually called only by 'init')"
	exit 1
	;;


esac


exit 0
[ups-monitor (text/plain, inline)]
#! /bin/sh
# skeleton	example file to build /etc/init.d/ scripts.
#		This file should be used to construct scripts for /etc/init.d.
#
#		Written by Miquel van Smoorenburg <miquels@cistron.nl>.
#		Modified for Debian GNU/Linux
#		by Ian Murdock <imurdock@gnu.ai.mit.edu>.
#
# Version:	@(#)skeleton  1.6  11-Nov-1996  miquels@cistron.nl
#
# This file by Peter S Galbraith <psg@debian.org> for the powstatd package.

PATH=/usr/local/sbin:/sbin:/bin:/usr/sbin:/usr/bin
DAEMON=/sbin/powstatd
NAME=powstatd
DESC="UPS Monitoring Daemon"

# Location of status file indicating whether power failure is occurring
upspath=/etc/ups-status

test -f $DAEMON || exit 0
test -f /etc/powstatd.conf || exit 0
if grep '^#!Unconfigured!' /etc/powstatd.conf >/dev/null; then
   echo "$NAME: unconfigured.  See \"man 8 powstatd\" for help about configuration."
   exit 0
fi

set -e

case "$1" in
  start)
    rm -f $upspath
    echo -n "Starting $DESC: $NAME"
    if $DAEMON > /dev/null 2>&1
    then
        echo "."
    else
        echo "... failed."
    fi
    ;;
  stop)
    echo -n "Stopping $DESC: $NAME"
    start-stop-daemon --stop --oknodo --quiet --exec $DAEMON
    echo "."
    ;;
  poweroff)
    # This is called from /etc/init.d/halt
    #  `/sbin/powstatd -k` queries the UPS for powerline status and 
    #  sends the kill signal to the UPS only if there is a powerline failure.
    echo -n "Checking to see if UPS should be shut down..."
    if $DAEMON -k > /dev/null 2>&1
    then
        echo " Done."
        exit 0;
    else
        echo " No.  Power is back up!"
        exit 1;
    fi
    ;;
  force-reload|restart)
    echo -n "Restarting $DESC: $NAME"
    rm -f $upspath
    start-stop-daemon --stop --oknodo --quiet --exec $DAEMON
    sleep 1
    $DAEMON
    echo "."
    ;;
  *)
    echo "Usage: /etc/init.d/$NAME {start|stop|poweroff|restart|force-reload}"
    exit 0
    ;;
esac

exit 0

Acknowledgement sent to Brian White <bcwhite@pobox.com>:
Extra info received and filed, but not forwarded. Full text and rfc822 format available.

Message #63 received at 55123-quiet@bugs.debian.org (full text, mbox):

From: Brian White <bcwhite@pobox.com>
To: Peter S Galbraith <GalbraithP@dfo-mpo.gc.ca>
Cc: Mitch Blevins <mblevin@debian.org>, 55123-quiet@bugs.debian.org
Subject: Re: I think /etc/init.d/powerfail shouldn't be a conffile
Date: Tue, 18 Jan 2000 22:43:08 -0500
[Message part 1 (text/plain, inline)]
> >                                               is to contact Miquel and
> > get his opinion.  I've dealt with him before (getting this stuff in to
> > the "halt" script originally)
> 
> I always thought they came that way upstream.  Interesting!

Mike is "up-stream".  He's the actual author of the program.


> If he agrees, the next step will be for us all to create new
> packages with the appropriate depends and conflicts, and either
> upload them all at the same time or first test them out with the
> new sysvinit package.

It'll be easy for us to depend on a specific version of sysvinit.  I
wonder if it's really necessary to ask him to put a "conflicts" line.
Perhaps it would be simpler if he just changed the name of the
"powerfail" script to something similar.


> I'd like to request the smallest of changes:

Done.


> BTW, you currently have upspath=/etc/ups-status in genpower.rc
> and upspath=/var/run/ups-status in powerfail.rc !  Which do we use?

Oops!  I originally had it in /var/run because that gets cleaned
automatically during system boot.  However, Mitch brought to my
attention that filesystems have been unmounted at that point.  While
/etc is guaranteed to be on the root filesystem (since it's needed for
initial boot), the same can't be said about /var.

So, we need to use /etc.


> I wonder if we can simplify this even more.  The powerfail file
> gets moved to sysvinit, so why have the halt script (another
> sysvinit file) call an external package to check for a file
> sysvinit created in the first place?

That's a good idea.  We might as well keep everything together if
possible.  Plus, as you say, "ups-monitor check" can be removed
completely.


> The only issue concerning $upspath that ups-monitor packages need
> to address is to delete the $upspath file on daemon start.  The
> `check' argument is no longer used; it's all done by the sysvinit
> package.

I _believe_ (reminded by a comment in the "powerfail" script) that the
system calls "powerfail stop" during boot.  It would be easy to verify
this.


> The hung state I can still get in now is when the power returns
> _after_ I have sent the kill signal to the UPS and have halted
> the system.  The UPS shuts down, but since the power is back
> there is nothing to tell it to turn back on.  At least that's a
> 30 second window;  smaller than it used to be.

The UPS will abort it's shutdown if power gets restored?  Hmmm...  That's
pretty dumb, if you ask me.

The solution to this that I can see, would to be to have your program
sit and monitor the line for 30 seconds.  If the power gets restored, you
return with the corresponding status.  If the power turns off, everything
is still okay because the system was "clean" before you got called.


I've incorporated all your changes.  Anything else you can think of?

                                          Brian
                                  ( bcwhite@pobox.com )

-------------------------------------------------------------------------------
          80% of people surveyed think they are above average drivers
[powerfail.rc (text/plain, inline)]
#! /bin/sh
#
# powerfail      This script is run when the UPS tells the system that the 
#                power has gone.  Tell everybody and start the shutdown based
#                on the failure type.  This script will also run when the 
#                power comes up again.
#
# Version:	/etc/init.d/powerfail (v2.0)
#
# Authors:	Brian White <bcwhite@pobox.com>
#		Peter S Galbraith <GalbraithP@dfo-mpo.gc.ca>
#		Mitch Blevins <mblevin@debian.org>
#



failtime=+5	# shutdown delay from initial power failure
btrytime=now	# shutdown delay from low-battery warning

failmsg="LINE POWER FAILURE -- SWITCHED TO BATTERY BACKUP"
btrymsg="BACKUP BATTERY LOW -- EMERGENCY SHUTDOWN"
okaymsg="LINE POWER RESTORED -- RESUMING NORMAL OPERATION"

sdnotify=15	# maximum time shutdown that sends notices



# Set the path.
PATH=/sbin:/etc:/bin:/usr/bin

# Set location of file containing PID of running shutdowns
spidpath=/var/run/shutdown.pid

# Set location of UPS status
upspath=/etc/ups-status



# See what happened.
case "$1" in


    start)
	# Called with a powerfail event, check to see if a shutdown is running
	if [ -f $spidpath ]
	then
	    # Shutdown is running, kill it to process the new event
	    shutdown -c >/dev/null 2>&1
	fi

	if [ "$failtime" != "now" ]; then
	    if [ `echo $failtime | sed -e 's/[^0-9]//g'` -gt "$sdnotify" ]; then
		echo "$failmsg" | wall
	    fi
	fi

	shutdown -h $failtime "$failmsg" &
	echo "fail" >$upspath
	;;


    now)
	# Called with a powerfail event, check to see if a shutdown is running
	if [ -f $spidpath ]
	then
	    # Shutdown is running, kill it to process the new event
	    shutdown -c >/dev/null 2>&1
	fi

	# Power is going down _now_
	shutdown -h $btrytime "$btrymsg" &
	echo "now" >$upspath
	;;


    stop)
	# Ok, power is good again. Say so on the console.
	if [ -f $spidpath ]
	then
	    # Only cancel if shutdown is running (system boot will call this)
	    shutdown -c "$okaymsg"
	fi
	rm -f $upspath
	;;


    *)
	echo "Usage: /etc/init.d/powerfail {start|now|stop}"
	echo " start: shutdown in $failtime minutes due to power failure"
	echo " now:   shutdown NOW due to eminent UPS battery failure"
	echo " stop:  cancel shutdown because power is back online"
	echo " (note that this script is usually called only by 'init')"
	exit 1
	;;


esac


exit 0
[halt.rc (text/plain, inline)]
#! /bin/sh
#
# halt		Execute the halt command.
#
# Version:      @(#)halt  2.75  19-May-1998  miquels@cistron.nl
#

PATH=/sbin:/bin:/usr/sbin:/usr/bin
halt="halt -d -f -i -p"
boot="reboot -d -f -i"
stat="/etc/ups-status"

# check the status of the line power
if [ -x /etc/init.d/ups-monitor ]; then

    if [ -r $stat ]; then

	if /etc/init.d/ups-monitor poweroff; then
	    echo "Line power failure -- halting..."
	    $halt
	else
	    echo "Line power restored -- rebooting..."
	    $boot
	fi

    fi

fi

echo "Halting..."
$halt
[genpower.rc (text/plain, inline)]
#! /bin/sh
#
# genpower	This script is used to start the UPS management daemon.	 When
#		called with "poweroff", this script will attempt to shutdown
#		the UPS in order to preserve the battery.  This should only
#		be done when going to run-level 0 ("system halt").
#
# Version:	/etc/init.d/genpower
#
# Author:	Brian White <bcwhite@pobox.com>
#

enabled=0
upsport=/dev/ups
upstype=apc-pnp

genpowerd=/sbin/genpowerd
genwrite=/sbin/genwrite
PATH=/usr/bin:/bin:/usr/sbin:/sbin


if [ ! -x $genpowerd ]
then
    exit 0
fi

if [ "$enabled" = 0 ]
then
    echo "/etc/init.d/genpower: UPS monitor daemon not enabled"
    exit 0
fi


#function setdumbsignal {
#    if [ "$1" = "apc-pnp" ]; then
#	echo -n "(switch to dumb-signalling mode) "
#	$genwrite -d $upsport "R"
#    fi
#}


case "$1" in

    start)
	echo -n "Starting UPS monitor: genpowerd "
	killall genpowerd >/dev/null 2>&1
#	setdumbsignal $upstype
	$genpowerd $upsport $upstype
	echo "."
	;;

    stop)
	echo -n "Stopping UPS monitor: genpowerd "
	killall genpowerd >/dev/null 2>&1
	echo "."
	;;

    poweroff)
	echo "Sending power-down signal to the UPS..."
	sync; sync; sleep 2
	$genpowerd -k $upsport $upstype >/dev/null 2>&1
	exit $?
	;;


    *)
	echo "Usage: /etc/init.d/genpower {start|stop|poweroff|check}"
	exit 1
	;;

esac


exit 0

Acknowledgement sent to Peter S Galbraith <GalbraithP@dfo-mpo.gc.ca>:
Extra info received and filed, but not forwarded. Full text and rfc822 format available.

Message #66 received at 55123-quiet@bugs.debian.org (full text, mbox):

From: Peter S Galbraith <GalbraithP@dfo-mpo.gc.ca>
To: Brian White <bcwhite@pobox.com>
Cc: Peter S Galbraith <GalbraithP@dfo-mpo.gc.ca>, Mitch Blevins <mblevin@debian.org>, 55123-quiet@bugs.debian.org
Subject: Re: I think /etc/init.d/powerfail shouldn't be a conffile
Date: Tue, 18 Jan 2000 23:00:37 -0500
Brian White wrote:

> > The only issue concerning $upspath that ups-monitor packages need
> > to address is to delete the $upspath file on daemon start.  The
> > `check' argument is no longer used; it's all done by the sysvinit
> > package.
> 
> I _believe_ (reminded by a comment in the "powerfail" script) that the
> system calls "powerfail stop" during boot.  It would be easy to verify
> this.

We definitely should. 
 
> > The hung state I can still get in now is when the power returns
> > _after_ I have sent the kill signal to the UPS and have halted
> > the system.  The UPS shuts down, but since the power is back
> > there is nothing to tell it to turn back on.  At least that's a
> > 30 second window;  smaller than it used to be.
> 
> The UPS will abort it's shutdown if power gets restored?  Hmmm...  That's
> pretty dumb, if you ask me.

No, the UPS will shutdown, but the power is back so it doesn't
know to turn itself back on.

> I've incorporated all your changes.  Anything else you can think of?

Only this:

halt.rc has
 stat="/etc/ups-status"

powerfail.rc has
 upspath=/etc/ups-status

I'd use the exact same variable name in both scripts.

Looks like we're done.  We'll have to see about handling the
conflict between present and future packages.  If sysvinit's
powerfail script is called something else, it avoids the filename
conflict but the current ups-monitor packages would be broken
anyway.   I'm not sure what the best alternative to having
sysvinit conflict with potato versions of our packages (and
earlier) would be.

Peter


Acknowledgement sent to Brian White <bcwhite@pobox.com>:
Extra info received and filed, but not forwarded. Full text and rfc822 format available.

Message #69 received at 55123-quiet@bugs.debian.org (full text, mbox):

From: Brian White <bcwhite@pobox.com>
To: Peter S Galbraith <GalbraithP@dfo-mpo.gc.ca>
Cc: Mitch Blevins <mblevin@debian.org>, 55123-quiet@bugs.debian.org
Subject: Re: I think /etc/init.d/powerfail shouldn't be a conffile
Date: Wed, 19 Jan 2000 07:34:37 -0500
> > > The only issue concerning $upspath that ups-monitor packages need
> > > to address is to delete the $upspath file on daemon start.  The
> > > `check' argument is no longer used; it's all done by the sysvinit
> > > package.
> >
> > I _believe_ (reminded by a comment in the "powerfail" script) that the
> > system calls "powerfail stop" during boot.  It would be easy to verify
> > this.
> 
> We definitely should.

I've put an "echo" in my local "powerfail".  Next time I reboot I'll
know if it was called.


> > > The hung state I can still get in now is when the power returns
> > > _after_ I have sent the kill signal to the UPS and have halted
> > > the system.  The UPS shuts down, but since the power is back
> > > there is nothing to tell it to turn back on.  At least that's a
> > > 30 second window;  smaller than it used to be.
> >
> > The UPS will abort it's shutdown if power gets restored?  Hmmm...  That's
> > pretty dumb, if you ask me.
> 
> No, the UPS will shutdown, but the power is back so it doesn't
> know to turn itself back on.

Oh.  Hmmm...  What make of UPS is it?  Does the manufacturer suggest
anything?


> > I've incorporated all your changes.  Anything else you can think of?
> 
> Only this:
> 
> halt.rc has
>  stat="/etc/ups-status"
> 
> powerfail.rc has
>  upspath=/etc/ups-status
> 
> I'd use the exact same variable name in both scripts.

<sheepish grin>  Yeah...  I just hate not having all the equal-signs
line up.  Done.


> Looks like we're done.  We'll have to see about handling the
> conflict between present and future packages.  If sysvinit's
> powerfail script is called something else, it avoids the filename
> conflict but the current ups-monitor packages would be broken
> anyway.   I'm not sure what the best alternative to having
> sysvinit conflict with potato versions of our packages (and
> earlier) would be.

Actually, I think the new sysvinit would work with the old "ups-monitor".
The only change to the ups-monitor is that it returns a code of 1 if
the power is back on instead of a code of 0.  Existing packages will
just always return a code of zero, thus going to halt.

                                          Brian
                                  ( bcwhite@pobox.com )

-------------------------------------------------------------------------------
          Until we are first independent, we cannot be interdependent.


Acknowledgement sent to Brian White <bcwhite@pobox.com>:
Extra info received and filed, but not forwarded. Full text and rfc822 format available.

Message #72 received at 55123-quiet@bugs.debian.org (full text, mbox):

From: Brian White <bcwhite@pobox.com>
To: Miquel van Smoorenburg <miquels@cistron.nl>
Cc: Peter S Galbraith <GalbraithP@dfo-mpo.gc.ca>, Mitch Blevins <mblevin@debian.org>, 55123-quiet@bugs.debian.org
Subject: Improved sysvinit UPS support
Date: Wed, 19 Jan 2000 07:54:59 -0500
[Message part 1 (text/plain, inline)]
Hi, Mike!

The other UPS-monitor maintainers and I have been working to improve the
way UPS systems shutdown and restart the system.

There were two problems we were working on:

1) As long as /etc/init.d/powerfail is a conffile, it is possible to end
   up with the "powerfail" script from one package getting used with
   another package (--remove pkg#1; --install pkg#2, don't install new
   conf file).

2) There is a race condition with some UPS systems such that if power
   returns before a complete power-off, then it will never turn off and
   the computer will remain in a halted state.

The solution we've come up with is a few changes to the final "halt"
script and to include the "powerfail" script as part of the "sysvinit"
package.

I've attached a common "powerfail" script that can be included with
sysvinit.  It's quite generic and so should be able to work with any
ups monitoring package.  The only thing of real note is the ups status
file "/etc/ups-status".  This file is created during a shutdown started
because of a UPS failure and is checked for in the new "halt" script to
determine how to shut down.

The new "halt" script looks for the "/etc/ups-status" file and only
calls the UPS shutdown if it exists.  It also checks the return status
from the "ups-monitor poweroff" result.  That call now returns "true"
if the system should halt or "false" if line-power has been restored
and the system should reboot instead.

There are two small "gotchas"...

1) "/etc/init.d/powerfail stop" needs to be called during boot or something
   else needs to remove any existing "/etc/ups-status" file.  We believe
   this to be the case today, but haven't verified it yet.  It's important
   that this not change in the future, though.

2) In order to avoid a bad state of packages, we need to make sure that
   there is no way to install the new set of packages that leaves an non-
   working system.  It'll be easy for us to require the new version of
   sysvinit.  I think that if you were to include the new "powerfail"
   script as something like "/etc/init.d/power-fail" (and adjust the
   "/etc/inittab" file accordingly), then there would be no need for
   any depends/conflicts in your package: there is no file conflict and
   existing ups monitors will work but won't support a reboot instead of
   halt should the line power be restored.

I think that covers everything, though there's lots of discussion available
in bug report #55123.  We look forward to your thoughts on this.

                                          Brian
                                  ( bcwhite@pobox.com )

-------------------------------------------------------------------------------
          Until we are first independent, we cannot be interdependent.
[powerfail.rc (text/plain, inline)]
#! /bin/sh
#
# powerfail      This script is run when the UPS tells the system that the 
#                power has gone.  Tell everybody and start the shutdown based
#                on the failure type.  This script will also run when the 
#                power comes up again.
#
# Version:	/etc/init.d/powerfail (v2.0)
#
# Authors:	Brian White <bcwhite@pobox.com>
#		Peter S Galbraith <GalbraithP@dfo-mpo.gc.ca>
#		Mitch Blevins <mblevin@debian.org>
#



failtime=+5	# shutdown delay from initial power failure
btrytime=now	# shutdown delay from low-battery warning

failmsg="LINE POWER FAILURE -- SWITCHED TO BATTERY BACKUP"
btrymsg="BACKUP BATTERY LOW -- EMERGENCY SHUTDOWN"
okaymsg="LINE POWER RESTORED -- RESUMING NORMAL OPERATION"

sdnotify=15	# maximum time shutdown that sends notices



# Set the path.
PATH=/sbin:/etc:/bin:/usr/bin

# Set location of file containing PID of running shutdowns
spidpath=/var/run/shutdown.pid

# Set location of UPS status
upspath=/etc/ups-status



# See what happened.
case "$1" in


    start)
	# Called with a powerfail event, check to see if a shutdown is running
	if [ -f $spidpath ]
	then
	    # Shutdown is running, kill it to process the new event
	    shutdown -c >/dev/null 2>&1
	fi

	if [ "$failtime" != "now" ]; then
	    if [ `echo $failtime | sed -e 's/[^0-9]//g'` -gt "$sdnotify" ]; then
		echo "$failmsg" | wall
	    fi
	fi

	shutdown -h $failtime "$failmsg" &
	echo "fail" >$upspath
	;;


    now)
	# Called with a powerfail event, check to see if a shutdown is running
	if [ -f $spidpath ]
	then
	    # Shutdown is running, kill it to process the new event
	    shutdown -c >/dev/null 2>&1
	fi

	# Power is going down _now_
	shutdown -h $btrytime "$btrymsg" &
	echo "now" >$upspath
	;;


    stop)
	# Ok, power is good again. Say so on the console.
	if [ -f $spidpath ]
	then
	    # Only cancel if shutdown is running (system boot will call this)
	    shutdown -c "$okaymsg"
	fi
	rm -f $upspath
	;;


    *)
	echo "Usage: /etc/init.d/powerfail {start|now|stop}"
	echo " start: shutdown in $failtime minutes due to power failure"
	echo " now:   shutdown NOW due to eminent UPS battery failure"
	echo " stop:  cancel shutdown because power is back online"
	echo " (note that this script is usually called only by 'init')"
	exit 1
	;;


esac


exit 0
[halt.rc (text/plain, inline)]
#! /bin/sh
#
# halt		Execute the halt command.
#
# Version:      @(#)halt  2.75  19-May-1998  miquels@cistron.nl
#

PATH=/sbin:/bin:/usr/sbin:/usr/bin
halt="halt -d -f -i -p"
boot="reboot -d -f -i"

upspath="/etc/ups-status"

# check the status of the line power
if [ -x /etc/init.d/ups-monitor ]; then

    if [ -r $upspath ]; then

	if /etc/init.d/ups-monitor poweroff; then
	    echo "Line power failure -- halting..."
	    $halt
	else
	    echo "Line power restored -- rebooting..."
	    $boot
	fi

    fi

fi

echo "Halting..."
$halt

Acknowledgement sent to Peter S Galbraith <GalbraithP@dfo-mpo.gc.ca>:
Extra info received and filed, but not forwarded. Full text and rfc822 format available.

Message #75 received at 55123-quiet@bugs.debian.org (full text, mbox):

From: Peter S Galbraith <GalbraithP@dfo-mpo.gc.ca>
To: Brian White <bcwhite@pobox.com>
Cc: Mitch Blevins <mblevin@debian.org>, 55123-quiet@bugs.debian.org, Peter S Galbraith <GalbraithP@dfo-mpo.gc.ca>
Subject: Re: I think /etc/init.d/powerfail shouldn't be a conffile
Date: Wed, 19 Jan 2000 09:31:51 -0500
Brian White wrote:

> >                         We'll have to see about handling the
> > conflict between present and future packages.  If sysvinit's
> > powerfail script is called something else, it avoids the filename
> > conflict but the current ups-monitor packages would be broken
> > anyway.
> 
> Actually, I think the new sysvinit would work with the old "ups-monitor".
> The only change to the ups-monitor is that it returns a code of 1 if
> the power is back on instead of a code of 0.  Existing packages will
> just always return a code of zero, thus going to halt.

You're right.  Good stuff.  And, btw, that was a nice summary you
sent to Miquel.

Peter


Acknowledgement sent to Brian White <bcwhite@pobox.com>:
Extra info received and filed, but not forwarded. Full text and rfc822 format available.

Message #78 received at 55123-quiet@bugs.debian.org (full text, mbox):

From: Brian White <bcwhite@pobox.com>
To: Miquel van Smoorenburg <miquels@cistron.nl>
Cc: Peter S Galbraith <GalbraithP@dfo-mpo.gc.ca>, mblevin@debian.org, 55123-quiet@bugs.debian.org
Subject: Improved sysvinit UPS support
Date: Sun, 13 Feb 2000 14:47:32 -0500
[Message part 1 (text/plain, inline)]
(I sent this a while back, but never heard anything in reply...)

Hi, Mike!

The other UPS-monitor maintainers and I have been working to improve the
way UPS systems shutdown and restart the system.

There were two problems we were working on:

1) As long as /etc/init.d/powerfail is a conffile, it is possible to end
   up with the "powerfail" script from one package getting used with
   another package (--remove pkg#1; --install pkg#2, don't install new
   conf file).

2) There is a race condition with some UPS systems such that if power
   returns before a complete power-off, then it will never turn off and
   the computer will remain in a halted state.

The solution we've come up with is a few changes to the final "halt"
script and to include the "powerfail" script as part of the "sysvinit"
package.

I've attached a common "powerfail" script that can be included with
sysvinit.  It's quite generic and so should be able to work with any
ups monitoring package.  The only thing of real note is the ups status
file "/etc/ups-status".  This file is created during a shutdown started
because of a UPS failure and is checked for in the new "halt" script to
determine how to shut down.

The new "halt" script looks for the "/etc/ups-status" file and only
calls the UPS shutdown if it exists.  It also checks the return status
from the "ups-monitor poweroff" result.  That call now returns "true"
if the system should halt or "false" if line-power has been restored
and the system should reboot instead.

There are two small "gotchas"...

1) "/etc/init.d/powerfail stop" needs to be called during boot or something
   else needs to remove any existing "/etc/ups-status" file.  We believe
   this to be the case today, but haven't verified it yet.  It's important
   that this not change in the future, though.

2) In order to avoid a bad state of packages, we need to make sure that
   there is no way to install the new set of packages that leaves an non-
   working system.  It'll be easy for us to require the new version of
   sysvinit.  I think that if you were to include the new "powerfail"
   script as something like "/etc/init.d/power-fail" (and adjust the
   "/etc/inittab" file accordingly), then there would be no need for
   any depends/conflicts in your package: there is no file conflict and
   existing ups monitors will work but won't support a reboot instead of
   halt should the line power be restored.

I think that covers everything, though there's lots of discussion available
in bug report #55123.  We look forward to your thoughts on this.

                                          Brian
                                  ( bcwhite@pobox.com )

-------------------------------------------------------------------------------
          Until we are first independent, we cannot be interdependent.
[powerfail.rc (text/plain, inline)]
#! /bin/sh
#
# powerfail      This script is run when the UPS tells the system that the 
#                power has gone.  Tell everybody and start the shutdown based
#                on the failure type.  This script will also run when the 
#                power comes up again.
#
# Version:	/etc/init.d/powerfail (v2.0)
#
# Authors:	Brian White <bcwhite@pobox.com>
#		Peter S Galbraith <GalbraithP@dfo-mpo.gc.ca>
#		Mitch Blevins <mblevin@debian.org>
#



failtime=+5	# shutdown delay from initial power failure
btrytime=now	# shutdown delay from low-battery warning

failmsg="LINE POWER FAILURE -- SWITCHED TO BATTERY BACKUP"
btrymsg="BACKUP BATTERY LOW -- EMERGENCY SHUTDOWN"
okaymsg="LINE POWER RESTORED -- RESUMING NORMAL OPERATION"

sdnotify=15	# maximum time shutdown that sends notices



# Set the path.
PATH=/sbin:/etc:/bin:/usr/bin

# Set location of file containing PID of running shutdowns
spidpath=/var/run/shutdown.pid

# Set location of UPS status
upspath=/etc/ups-status



# See what happened.
case "$1" in


    start)
	# Called with a powerfail event, check to see if a shutdown is running
	if [ -f $spidpath ]
	then
	    # Shutdown is running, kill it to process the new event
	    shutdown -c >/dev/null 2>&1
	fi

	if [ "$failtime" != "now" ]; then
	    if [ `echo $failtime | sed -e 's/[^0-9]//g'` -gt "$sdnotify" ]; then
		echo "$failmsg" | wall
	    fi
	fi

	shutdown -h $failtime "$failmsg" &
	echo "fail" >$upspath
	;;


    now)
	# Called with a powerfail event, check to see if a shutdown is running
	if [ -f $spidpath ]
	then
	    # Shutdown is running, kill it to process the new event
	    shutdown -c >/dev/null 2>&1
	fi

	# Power is going down _now_
	shutdown -h $btrytime "$btrymsg" &
	echo "now" >$upspath
	;;


    stop)
	# Ok, power is good again. Say so on the console.
	if [ -f $spidpath ]
	then
	    # Only cancel if shutdown is running (system boot will call this)
	    shutdown -c "$okaymsg"
	fi
	rm -f $upspath
	;;


    *)
	echo "Usage: /etc/init.d/powerfail {start|now|stop}"
	echo " start: shutdown in $failtime minutes due to power failure"
	echo " now:   shutdown NOW due to eminent UPS battery failure"
	echo " stop:  cancel shutdown because power is back online"
	echo " (note that this script is usually called only by 'init')"
	exit 1
	;;


esac


exit 0

[halt.rc (text/plain, inline)]
#! /bin/sh
#
# halt		Execute the halt command.
#
# Version:      @(#)halt  2.75  19-May-1998  miquels@cistron.nl
#

PATH=/sbin:/bin:/usr/sbin:/usr/bin
halt="halt -d -f -i -p"
boot="reboot -d -f -i"

upspath="/etc/ups-status"

# check the status of the line power
if [ -x /etc/init.d/ups-monitor ]; then

    if [ -r $upspath ]; then

	if /etc/init.d/ups-monitor poweroff; then
	    echo "Line power failure -- halting..."
	    $halt
	else
	    echo "Line power restored -- rebooting..."
	    $boot
	fi

    fi

fi

echo "Halting..."
$halt


Severity set to `wishlist'. Request was from Brian White <bcwhite@pobox.com> to control@bugs.debian.org. Full text and rfc822 format available.

Changed Bug title. Request was from Brian White <bcwhite@pobox.com> to control@bugs.debian.org. Full text and rfc822 format available.

Bug reassigned from package `powstatd' to `sysvinit'. Request was from Brian White <bcwhite@pobox.com> to control@bugs.debian.org. Full text and rfc822 format available.

Severity set to `wishlist'. Request was from Brian White <bcwhite@pobox.com> to control@bugs.debian.org. Full text and rfc822 format available.

Changed Bug title. Request was from Brian White <bcwhite@pobox.com> to control@bugs.debian.org. Full text and rfc822 format available.

Bug reassigned from package `sysvinit' to `sysvinit'. Request was from Brian White <bcwhite@pobox.com> to control@bugs.debian.org. Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Miquel van Smoorenburg <miquels@cistron.nl>:
Bug#55123; Package sysvinit. Full text and rfc822 format available.

Acknowledgement sent to Peter S Galbraith <GalbraithP@dfo-mpo.gc.ca>:
Extra info received and forwarded to list. Copy sent to Miquel van Smoorenburg <miquels@cistron.nl>. Full text and rfc822 format available.

Message #95 received at 55123@bugs.debian.org (full text, mbox):

From: Peter S Galbraith <GalbraithP@dfo-mpo.gc.ca>
To: 55123@bugs.debian.org
Cc: Peter S Galbraith <GalbraithP@dfo-mpo.gc.ca>, Brian White <bcwhite@pobox.com>, mblevin@debian.org
Subject: Re: Bug #55123 Improved sysvinit UPS support
Date: Mon, 29 Jan 2001 11:50:40 -0500
I just noted that policy (actually upgrading-checklist.text.gz)
says:

     - If your package has a daemon startup script in /etc/init.d/,
       and that script has parameters a system administrator may need,
       you need to modify the script to read values from a conffile
       placed in /etc/default/ directory. This conffile maybe sourced
       by the init.d script to determine the sonfigurable values (and
       the conffile may contain only variable settings and comments).

So the new etc/init.d/power-fail script will need to move the
`failtime' variable to a file in /etc/default/:

 failtime=+5     # shutdown delay from initial power failure

-- 
Peter Galbraith, research scientist          <GalbraithP@dfo-mpo.gc.ca>
Maurice Lamontagne Institute, Department of Fisheries and Oceans Canada
P.O. Box 1000, Mont-Joli Qc, G5H 3Z4 Canada. 418-775-0852 FAX: 775-0546
    6623'rd GNU/Linux user at the Counter - http://counter.li.org/ 



Information forwarded to debian-bugs-dist@lists.debian.org, Miquel van Smoorenburg <miquels@cistron.nl>:
Bug#55123; Package sysvinit. Full text and rfc822 format available.

Acknowledgement sent to Brian White <bcwhite@pobox.com>:
Extra info received and forwarded to list. Copy sent to Miquel van Smoorenburg <miquels@cistron.nl>. Full text and rfc822 format available.

Message #100 received at 55123@bugs.debian.org (full text, mbox):

From: Brian White <bcwhite@pobox.com>
To: Peter S Galbraith <GalbraithP@dfo-mpo.gc.ca>
Cc: 55123@bugs.debian.org, mblevin@debian.org
Subject: Re: Bug #55123 Improved sysvinit UPS support
Date: Wed, 31 Jan 2001 23:14:50 -0500
> I just noted that policy (actually upgrading-checklist.text.gz)
> says:
> 
>      - If your package has a daemon startup script in /etc/init.d/,
>        and that script has parameters a system administrator may need,
>        you need to modify the script to read values from a conffile
>        placed in /etc/default/ directory. This conffile maybe sourced
>        by the init.d script to determine the sonfigurable values (and
>        the conffile may contain only variable settings and comments).
> 
> So the new etc/init.d/power-fail script will need to move the
> `failtime' variable to a file in /etc/default/:
> 
>  failtime=+5     # shutdown delay from initial power failure

Failtime is not really supposed to be played with, though you can if
you wish.  It's placed at the beginning of the script for convienence,
not because it's a configuration setting.

                                          Brian
                                  ( bcwhite@pobox.com )

-------------------------------------------------------------------------------
        Premature optimization is the root of all evil.  -- Donald Knuth



Information forwarded to debian-bugs-dist@lists.debian.org, Miquel van Smoorenburg <miquels@cistron.nl>:
Bug#55123; Package sysvinit. Full text and rfc822 format available.

Acknowledgement sent to Peter S Galbraith <GalbraithP@dfo-mpo.gc.ca>:
Extra info received and forwarded to list. Copy sent to Miquel van Smoorenburg <miquels@cistron.nl>. Full text and rfc822 format available.

Message #105 received at 55123@bugs.debian.org (full text, mbox):

From: Peter S Galbraith <GalbraithP@dfo-mpo.gc.ca>
To: Brian White <bcwhite@pobox.com>
Cc: Peter S Galbraith <GalbraithP@dfo-mpo.gc.ca>, 55123@bugs.debian.org, mblevin@debian.org
Subject: Re: Bug #55123 Improved sysvinit UPS support
Date: Wed, 31 Jan 2001 23:23:02 -0500
Brian White wrote:

> > I just noted that policy (actually upgrading-checklist.text.gz)
> > says:
> > 
> >      - If your package has a daemon startup script in /etc/init.d/,
> >        and that script has parameters a system administrator may need,
> >        you need to modify the script to read values from a conffile
> >        placed in /etc/default/ directory. This conffile maybe sourced
> >        by the init.d script to determine the sonfigurable values (and
> >        the conffile may contain only variable settings and comments).
> > 
> > So the new etc/init.d/power-fail script will need to move the
> > `failtime' variable to a file in /etc/default/:
> > 
> >  failtime=+5     # shutdown delay from initial power failure
> 
> Failtime is not really supposed to be played with, though you can if
> you wish.  It's placed at the beginning of the script for convienence,
> not because it's a configuration setting.
> 
>                                           Brian
>                                   ( bcwhite@pobox.com )

I don't know;  my UPS is big enough that I can set a failtime of
50 minutes, minimizing downtime.

Peter



Changed Bug submitter from Peter S Galbraith <GalbraithP@dfo-mpo.gc.ca> to Peter S Galbraith <psg@debian.org>. Request was from Peter S Galbraith <psg@debian.org> to control@bugs.debian.org. Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Miquel van Smoorenburg <miquels@cistron.nl>:
Bug#55123; Package sysvinit. Full text and rfc822 format available.

Acknowledgement sent to Peter S Galbraith <psg@debian.org>:
Extra info received and forwarded to list. Copy sent to Miquel van Smoorenburg <miquels@cistron.nl>. Full text and rfc822 format available.

Message #112 received at 55123@bugs.debian.org (full text, mbox):

From: Peter S Galbraith <psg@debian.org>
To: "Marek Michalkiewicz" <marekm@amelek.gda.pl>
Cc: 157354@bugs.debian.org, 55123@bugs.debian.org
Subject: Re: sysvinit: should reboot after failed UPS poweroff
Date: Tue, 28 Oct 2003 11:13:20 -0500
Marek Michalkiewicz <marekm@amelek.gda.pl> wrote:

> Package: sysvinit
> Version: 2.84-3
> Severity: normal
> 
> Many UPS types can only be powered off if running on battery.
> If the system is shutting down, then the power comes back just
> before running /etc/init.d/halt, the system remains halted (or
> powered off, if ATX) and requires manual intervention.
> 
> I'd suggest to add a reboot command in /etc/init.d/halt after
> the "/etc/init.d/ups-monitor poweroff" command.  This way, the
> system is rebooted (instead of halted) after the power is back.
> 
> (Alternatively, UPS monitor like "nut" could do that - if you
> think that would be better, please reassign this bug to nut.)
> 
> Thanks,
> Marek

This bug could probably be merged with #55123 since that bug's patch
implements this functionality.  (It's not a complete patch, but all the
UPS interface is there).

I don't know whether this will ever be implemented (I doubt it, it's
3.78 years-old now), but the maintainer has not tagged it as wont-fix.

-- 
Peter S. Galbraith, Debian Developer          <psg@debian.org>
                                 http://people.debian.org/~psg
GPG key 1024/D2A913A1 - 97CE 866F F579 96EE  6E68 8170 35FF 799E



Tags added: patch Request was from Peter S Galbraith <psg@debian.org> to control@bugs.debian.org. Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Miquel van Smoorenburg <miquels@cistron.nl>:
Bug#55123; Package sysvinit. Full text and rfc822 format available.

Acknowledgement sent to Brian White <bcwhite@precidia.com>:
Extra info received and forwarded to list. Copy sent to Miquel van Smoorenburg <miquels@cistron.nl>. Full text and rfc822 format available.

Message #119 received at 55123@bugs.debian.org (full text, mbox):

From: Brian White <bcwhite@precidia.com>
To: 55123@bugs.debian.org
Subject: UPS Patch to SysVInit
Date: Fri, 14 Nov 2003 08:23:28 -0500
Would it be possible to get the patch listed in bug #55123 applied to
the "sysvinit" package before the next release?  I just merged it with
another bug report with about a failed system restart, so it's really
more than just a "wishlist" bug.

In fact, a power failure we had last night caused my the very same
problem...  My machine started to shutdown but then the line power
returned.  In the end, the UPS did not power off and the machine stayed
in the halted state.  The patch in bug #55123 fixes this race condition.

Thanks!

                                          Brian
                                 ( bcwhite@precidia.com )

-------------------------------------------------------------------------------
    It seems that anything people have learned prior to puberty takes on the
  status of an immutable truth (this is something well understood by parents,
    governments, and religions). Rational explanations of why some previous
    belief might be incompatible with the behavior of nature, and a careful
       explanation of the actual behavior of nature are of little avail.



Severity set to `normal'. Request was from Brian White <bcwhite@precidia.com> to control@bugs.debian.org. Full text and rfc822 format available.

Merged 55123 157354. Request was from Brian White <bcwhite@precidia.com> to control@bugs.debian.org. Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Miquel van Smoorenburg <miquels@cistron.nl>:
Bug#55123; Package sysvinit. Full text and rfc822 format available.

Acknowledgement sent to Miquel van Smoorenburg <miquels@cistron.net>:
Extra info received and forwarded to list. Copy sent to Miquel van Smoorenburg <miquels@cistron.nl>. Full text and rfc822 format available.

Message #128 received at 55123@bugs.debian.org (full text, mbox):

From: Miquel van Smoorenburg <miquels@cistron.net>
To: Brian White <bcwhite@precidia.com>
Cc: 55123@bugs.debian.org
Subject: Re: Bug#55123: UPS Patch to SysVInit
Date: Fri, 14 Nov 2003 15:14:34 +0100
On 2003.11.14 14:23, Brian White wrote:
> Would it be possible to get the patch listed in bug #55123 applied to
> the "sysvinit" package before the next release?  I just merged it with
> another bug report with about a failed system restart, so it's really
> more than just a "wishlist" bug.
> 
> In fact, a power failure we had last night caused my the very same
> problem...  My machine started to shutdown but then the line power
> returned.  In the end, the UPS did not power off and the machine stayed
> in the halted state.  The patch in bug #55123 fixes this race condition.

I'll have a look at it. I've been actively working on the package
and there will be a new release soon (maybe even a couple).

Mike.



Information forwarded to debian-bugs-dist@lists.debian.org:
Bug#55123; Package sysvinit. Full text and rfc822 format available.

Acknowledgement sent to Miquel van Smoorenburg <miquels@cistron.nl>:
Extra info received and forwarded to list. Full text and rfc822 format available.

Message #133 received at 55123@bugs.debian.org (full text, mbox):

From: Miquel van Smoorenburg <miquels@cistron.nl>
To: Brian White <bcwhite@precidia.com>, 55123@bugs.debian.org
Subject: Re: Bug#55123: UPS Patch to SysVInit
Date: Sat, 15 Nov 2003 01:24:57 +0100
On Fri, 14 Nov 2003 15:14:34, Miquel van Smoorenburg wrote:
> On 2003.11.14 14:23, Brian White wrote:
> > Would it be possible to get the patch listed in bug #55123 applied to
> > the "sysvinit" package before the next release?  I just merged it with
> > another bug report with about a failed system restart, so it's really
> > more than just a "wishlist" bug.
> > 
> > In fact, a power failure we had last night caused my the very same
> > problem...  My machine started to shutdown but then the line power
> > returned.  In the end, the UPS did not power off and the machine stayed
> > in the halted state.  The patch in bug #55123 fixes this race condition.
> 
> I'll have a look at it. I've been actively working on the package
> and there will be a new release soon (maybe even a couple).

Okay, I've reviewed this.

I think you're taking the wrong direction. Sysvinit and other packages
(it would be initscripts now) do not have to know about all this UPS
stuff at all.

All packages in Debian that have something in common, create a -common
package. For example, nfs-common, shared by both nfs-user-server and
nfs-kernel-server. In this case I suggest that a upsd-common package is
created that contains /etc/init.d/ups-monitor, and /etc/init.d/ups-halt.

/etc/init.d/ups-halt would be linked to S89ups-halt in /etc/rc[06].d
and would do what the proposed extensions to the halt script would do.

I also think a new virtual packages should be created, "upsd" or
whatever, and every powerd etc package would Provide: and Conflicts:
that package as well as Depends: upsd-common.

That way the problem would be solved in a nice and clean way, and
it would also be more the "Debian" way of doing things.

What do you think ? Am I overlooking something ?

Mike.



Information forwarded to debian-bugs-dist@lists.debian.org, Miquel van Smoorenburg <miquels@cistron.nl>:
Bug#55123; Package sysvinit. Full text and rfc822 format available.

Acknowledgement sent to Brian White <bcwhite@precidia.com>:
Extra info received and forwarded to list. Copy sent to Miquel van Smoorenburg <miquels@cistron.nl>. Full text and rfc822 format available.

Message #138 received at 55123@bugs.debian.org (full text, mbox):

From: Brian White <bcwhite@precidia.com>
To: Miquel van Smoorenburg <miquels@cistron.nl>
Cc: 55123@bugs.debian.org, Peter S Galbraith <GalbraithP@dfo-mpo.gc.ca>, Mitch Blevins <mblevin@debian.org>
Subject: Re: Bug#55123: UPS Patch to SysVInit
Date: Mon, 17 Nov 2003 08:17:19 -0500
> I think you're taking the wrong direction. Sysvinit and other packages
> (it would be initscripts now) do not have to know about all this UPS
> stuff at all.

My worry is merely compatibility.  In that case, the ups-common package
is assuming knowledge of the sysvinit package and how it will unmount
filesystems, what index (i.e. S90) it will execute the "halt" command,
and what is done within that script.  For example, I notice that the
halt script has added RAID shutdown.  Is it safe for us to skip that or
anything else that might be added in the future?

By including the change to the halt script in the original package, there
is no danger of ever having an incompatibility.  Including the powerfail
script is mostly a convenience, then, to avoid such a ups-common package
but is also good from a consistency point of view since it is already
being called (with parameters) by the stock /etc/inittab file.

In essence, we don't want to add knowledge about UPS monitoring to
the sysvinit package; only add knowledge of how to deal with power failures.
There is already a call to "ups-monitor poweroff" in the "halt script".
This is merely improving upon it.

                                          Brian
                                 ( bcwhite@precidia.com )

-------------------------------------------------------------------------------
                    I can resist anything except temptation.



Information forwarded to debian-bugs-dist@lists.debian.org:
Bug#55123; Package sysvinit. Full text and rfc822 format available.

Acknowledgement sent to Miquel van Smoorenburg <miquels@cistron.nl>:
Extra info received and forwarded to list. Full text and rfc822 format available.

Message #143 received at 55123@bugs.debian.org (full text, mbox):

From: Miquel van Smoorenburg <miquels@cistron.nl>
To: Brian White <bcwhite@precidia.com>, 55123@bugs.debian.org
Cc: Peter S Galbraith <GalbraithP@dfo-mpo.gc.ca>, Mitch Blevins <mblevin@debian.org>
Subject: Re: Bug#55123: UPS Patch to SysVInit
Date: Mon, 17 Nov 2003 15:13:19 +0100
On 2003.11.17 14:17, Brian White wrote:
> > I think you're taking the wrong direction. Sysvinit and other packages
> > (it would be initscripts now) do not have to know about all this UPS
> > stuff at all.
> 
> My worry is merely compatibility.  In that case, the ups-common package
> is assuming knowledge of the sysvinit package and how it will unmount
> filesystems, what index (i.e. S90) it will execute the "halt" command,

Correct. If you read Debian policy, when creating packages that have an
init script, you should talk to the sysvinit maintainer to decide what
index to use for starting/stopping for exactly this reason.

Not that *anyone* ever bothered to do that, ofcourse.

> and what is done within that script.  For example, I notice that the
> halt script has added RAID shutdown.

No, it hasn't. The "halt" binary shuts down all IDE disks before poweroff,
because of a bug in the kernel IDE driver. The kernel IDE driver should
hook into the "poweroff event" and make sure the IDE write cache on the
drive is flushed before poweroff, but didn't until recently.

Now it appeared that doing this actually corrupted some RAID setups due
to bugs in the kernel RAID drivers. So yet another workaround was added
that *doesn't* flush/shutdown the IDE disks if RAID is detected. That is
all. The halt script definitely doesn't do RAID shutdown.

> Is it safe for us to skip that or
> anything else that might be added in the future?

It should be.

> By including the change to the halt script in the original package, there
> is no danger of ever having an incompatibility.  Including the powerfail
> script is mostly a convenience, then, to avoid such a ups-common package
> but is also good from a consistency point of view since it is already
> being called (with parameters) by the stock /etc/inittab file.

What is being called by inittab ? I'm confused. You mean /etc/init.d/halt
here ?

> In essence, we don't want to add knowledge about UPS monitoring to
> the sysvinit package; only add knowledge of how to deal with power failures.
> There is already a call to "ups-monitor poweroff" in the "halt script".

Which should be taken out.

> This is merely improving upon it.

I really really really want to make things more modular instead of less.
I don't want to create monolithic scripts that know of all kinds of
packages that might not even be installed. Modular == good.

The only things is that actually a lot of S/K indexes are wrong. For
example S90 halt really should be at S99halt, since it is the last
thing that can ever be executed. No use having it at 90. Please read
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=216028 for more
thoughts on this. Because of that, I really want to reorganize things
instead of making it worse.

Mike.



Information stored:
Bug#55123; Package sysvinit. Full text and rfc822 format available.

Acknowledgement sent to Brian White <bcwhite@precidia.com>:
Extra info received and filed, but not forwarded. Full text and rfc822 format available.

Message #148 received at 55123-quiet@bugs.debian.org (full text, mbox):

From: Brian White <bcwhite@precidia.com>
To: Miquel van Smoorenburg <miquels@cistron.nl>
Cc: 55123-quiet@bugs.debian.org, Peter S Galbraith <GalbraithP@dfo-mpo.gc.ca>, Mitch Blevins <mblevin@debian.org>
Subject: Re: Bug#55123: UPS Patch to SysVInit
Date: Mon, 17 Nov 2003 09:46:42 -0500
> Now it appeared that doing this actually corrupted some RAID setups due
> to bugs in the kernel RAID drivers. So yet another workaround was added
> that *doesn't* flush/shutdown the IDE disks if RAID is detected. That is
> all. The halt script definitely doesn't do RAID shutdown.

Okay.  I just saw some sort of RAID stuff that wasn't there the last time
I looked at the script (way, waaaay back).


> > Is it safe for us to skip that or
> > anything else that might be added in the future?
> 
> It should be.
> 
> > By including the change to the halt script in the original package, there
> > is no danger of ever having an incompatibility.  Including the "powerfail"
> > script is mostly a convenience, then, to avoid such a ups-common package
> > but is also good from a consistency point of view since it is already
> > being called (with parameters) by the stock /etc/inittab file.
> 
> What is being called by inittab ? I'm confused. You mean /etc/init.d/halt
> here ?

No, /etc/init.d/powerfail is called from /etc/inittab (rules pf, pn, po)
so one would expect that script to be include with the sysvinit package.


> > In essence, we don't want to add knowledge about UPS monitoring to
> > the sysvinit package; only add knowledge of how to deal with power failures.
> > There is already a call to "ups-monitor poweroff" in the "halt script".
> 
> Which should be taken out.
> 
> > This is merely improving upon it.
> 
> I really really really want to make things more modular instead of less.
> I don't want to create monolithic scripts that know of all kinds of
> packages that might not even be installed. Modular == good.

For the most part, I agree with you.  It's my opinion, though, that this is
better served being an integral part of the init package.  The other guys
and I tried hard to make this a very simple and generic solution.  However,
if you would rather see it separated, then we'll abide by your wishes.  It
would have been nice to get this decision 4 years ago, though...


> The only things is that actually a lot of S/K indexes are wrong. For
> example S90 halt really should be at S99halt, since it is the last
> thing that can ever be executed. No use having it at 90. Please read
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=216028 for more
> thoughts on this. Because of that, I really want to reorganize things
> instead of making it worse.

I wondered about that.  So, will S90halt become S99halt?  If so, then S89ups
would be a bad thing because it's possible that no scripts in between "89"
and "99" would get executed.  ...which brings me back to the consistancy
reasons.

                                          Brian
                                 ( bcwhite@precidia.com )

-------------------------------------------------------------------------------
                    I can resist anything except temptation.



Information stored:
Bug#55123; Package sysvinit. Full text and rfc822 format available.

Acknowledgement sent to Peter S Galbraith <psg@debian.org>:
Extra info received and filed, but not forwarded. Full text and rfc822 format available.

Message #153 received at 55123-quiet@bugs.debian.org (full text, mbox):

From: Peter S Galbraith <psg@debian.org>
To: Brian White <bcwhite@precidia.com>
Cc: Miquel van Smoorenburg <miquels@cistron.nl>, 55123-quiet@bugs.debian.org, Mitch Blevins <mblevin@debian.org>
Subject: Re: Bug#55123: UPS Patch to SysVInit
Date: Tue, 18 Nov 2003 10:57:27 -0500
Brian White <bcwhite@precidia.com> wrote:

>                                       It's my opinion, though, that this is
> better served being an integral part of the init package. 

Same here.
>                                                            The other guys
> and I tried hard to make this a very simple and generic solution.  However,
> if you would rather see it separated, then we'll abide by your wishes.  It
> would have been nice to get this decision 4 years ago, though...

Let's not wait another 4 years to do something about this.

Mike, if your decision final?
If so, Brian, will you prepare a ups-common package?
If so, I'll update powstatd to depend on it.

Peter



Tags added: wontfix Request was from Thomas Hood <jdthood@yahoo.co.uk> to control@bugs.debian.org. Full text and rfc822 format available.

Disconnected #55123 from all other report(s). Request was from Thomas Hood <jdthood@yahoo.co.uk> to control@bugs.debian.org. Full text and rfc822 format available.

Severity set to `wishlist'. Request was from Thomas Hood <jdthood@yahoo.co.uk> to control@bugs.debian.org. Full text and rfc822 format available.

Bug reassigned from package `sysvinit' to `initscripts'. Request was from Thomas Hood <jdthood@yahoo.co.uk> to control@bugs.debian.org. Full text and rfc822 format available.

Changed Bug title. Request was from Thomas Hood <jdthood@yahoo.co.uk> to control@bugs.debian.org. Full text and rfc822 format available.

Tags removed: patch Request was from Thomas Hood <jdthood@yahoo.co.uk> to control@bugs.debian.org. Full text and rfc822 format available.

Reply sent to Roger Leigh <rleigh@codelibre.net>:
You have taken responsibility. (Fri, 20 Apr 2012 23:57:55 GMT) Full text and rfc822 format available.

Notification sent to Peter S Galbraith <psg@debian.org>:
Bug acknowledged by developer. (Fri, 20 Apr 2012 23:57:55 GMT) Full text and rfc822 format available.

Message #170 received at 55123-done@bugs.debian.org (full text, mbox):

From: Roger Leigh <rleigh@codelibre.net>
To: 55361-done@bugs.debian.org, 16273-done@bugs.debian.org, 58777-done@bugs.debian.org, 42069-done@bugs.debian.org, 55123-done@bugs.debian.org, 39023-done@bugs.debian.org, 86461-done@bugs.debian.org, 132408-done@bugs.debian.org, 138419-done@bugs.debian.org, 145689-done@bugs.debian.org, 157354-done@bugs.debian.org, 197750-done@bugs.debian.org, 239446-done@bugs.debian.org, 240068-done@bugs.debian.org, 243159-done@bugs.debian.org, 245179-done@bugs.debian.org, 248177-done@bugs.debian.org, 250989-done@bugs.debian.org, 254311-done@bugs.debian.org, 260817-done@bugs.debian.org, 272428-done@bugs.debian.org, 288016-done@bugs.debian.org, 311839-done@bugs.debian.org, 312281-done@bugs.debian.org, 338299-done@bugs.debian.org, 343645-done@bugs.debian.org, 345741-done@bugs.debian.org, 367574-done@bugs.debian.org, 508686-done@bugs.debian.org, 513237-done@bugs.debian.org, 548877-done@bugs.debian.org
Subject: Close old and unfixable sysvinit bugs
Date: Sat, 21 Apr 2012 00:52:18 +0100
This bug is being closed as part of a cleanup of the old bug
reports in the sysvinit package, in an attempt to make it easier
to address the bug reports which actually are fixable.  Some
reasons:

- Not a bug and/or it's a patch which will not be applied
- It will not be fixed, ever for various reasons
- Problem is not fixable in sysvinit or not our responsibility
- A better solution has become available in the interim
- No activity or submitter response in over a decade or more


Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux             http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?       http://gutenprint.sourceforge.net/
   `-    GPG Public Key: 0x25BFB848   Please GPG sign your mail.




Bug archived. Request was from Debbugs Internal Request <owner@bugs.debian.org> to internal_control@bugs.debian.org. (Sat, 19 May 2012 07:36:37 GMT) Full text and rfc822 format available.

Send a report that this bug log contains spam.


Debian bug tracking system administrator <owner@bugs.debian.org>. Last modified: Fri Apr 18 03:30:19 2014; Machine Name: buxtehude.debian.org

Debian Bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.