Report forwarded to debian-bugs-dist@lists.debian.org, Peter S Galbraith <psg@debian.org>:
Bug#55123; Package powstatd.
debian-bugs-dist@lists.debian.orgPeter S Galbraith
Subject: Bug#55123: I think /etc/init.d/powerfail shouldn't be a conffile
Reply-To: Peter S Galbraith , 55123@bugs.debian.org
Resent-From: Peter S Galbraith
Resent-To: debian-bugs-dist@lists.debian.org
Resent-CC: Peter S Galbraith
Resent-Date: Sat, 15 Jan 2000 00:54:00 GMT
Resent-Message-ID:
Resent-Sender: owner@bugs.debian.org
X-Debian-PR-Message: report 55123
X-Debian-PR-Package: powstatd
X-Debian-PR-Keywords:
X-Loop: owner@bugs.debian.org
Received: via spool by bugs@bugs.debian.org id=B.94787011517241
(code B ref -1); Sat, 15 Jan 2000 00:54:00 GMT
Message-Id: <200001141714.MAA12742@mixing.qc.dfo.ca>
To: Mitch Blevins , Brian White ,
submit@bugs.debian.org
cc: Peter S Galbraith
Date: Fri, 14 Jan 2000 12:14:47 -0500
From: Peter S Galbraith
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
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>.
-t
From: owner@bugs.debian.org (Debian Bug Tracking System)
To: Peter S Galbraith
Subject: Bug#55123: Acknowledgement (I think /etc/init.d/powerfail shouldn't be a conffile)
Message-ID:
In-Reply-To: <200001141714.MAA12742@mixing.qc.dfo.ca>
References: <200001141714.MAA12742@mixing.qc.dfo.ca>
X-Debian-PR-Message: ack 55123
Thank you for the problem report you have sent regarding Debian.
This is an automatically generated reply, to let you know your message has
been received. It is being forwarded to the developers mailing list for
their attention; they will reply in due course.
Your message has been sent to the package maintainer(s):
Peter S Galbraith
If you wish to submit further information on your problem, please send
it to 55123@bugs.debian.org (and *not* to
bugs@bugs.debian.org).
Please do not reply to the address at the top of this message,
unless you wish to report a problem with the Bug-tracking system.
Darren Benham
(administrator, Debian Bugs database)
Received: (at submit) by bugs.debian.org; 14 Jan 2000 17:15:15 +0000
Received: (qmail 17237 invoked from network); 14 Jan 2000 17:15:15 -0000
Received: from mixing.qc.dfo-mpo.gc.ca (HELO mixing.qc.dfo.ca) (207.216.183.21)
by master.debian.org with SMTP; 14 Jan 2000 17:15:15 -0000
Received: from mixing.qc.dfo.ca (rhogee@localhost [127.0.0.1])
by mixing.qc.dfo.ca (8.9.3/8.8.5) with ESMTP id MAA12742;
Fri, 14 Jan 2000 12:14:47 -0500
Message-Id: <200001141714.MAA12742@mixing.qc.dfo.ca>
To: Mitch Blevins , Brian White ,
submit@bugs.debian.org
cc: Peter S Galbraith
Subject: I think /etc/init.d/powerfail shouldn't be a conffile
Date: Fri, 14 Jan 2000 12:14:47 -0500
From: Peter S Galbraith
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.
debian-bugs-dist@lists.debian.orgPeter S Galbraith
Subject: Bug#55123: I think /etc/init.d/powerfail shouldn't be a conffile
Reply-To: Mitch Blevins , 55123@bugs.debian.org
Resent-From: Mitch Blevins
Orignal-Sender: Mitch Blevins
Resent-To: debian-bugs-dist@lists.debian.org
Resent-CC: Peter S Galbraith
Resent-Date: Sat, 15 Jan 2000 02:33:13 GMT
Resent-Message-ID:
Resent-Sender: owner@bugs.debian.org
X-Debian-PR-Message: report 55123
X-Debian-PR-Package: powstatd
X-Debian-PR-Keywords:
X-Loop: owner@bugs.debian.org
Received: via spool by 55123-bugs@bugs.debian.org id=B55123.94790335213358
(code B ref 55123); Sat, 15 Jan 2000 02:33:13 GMT
Date: Fri, 14 Jan 2000 20:35:07 -0500
From: Mitch Blevins
To: Peter S Galbraith
Cc: 55123@bugs.debian.org
Message-ID: <20000114203507.A12285@mindspring.com>
References: <200001141714.MAA12742@mixing.qc.dfo.ca>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Mutt/1.0i
In-Reply-To: <200001141714.MAA12742@mixing.qc.dfo.ca>; from GalbraithP@dfo-mpo.gc.ca on Fri, Jan 14, 2000 at 12:14:47PM -0500
Sender: Mitch Blevins
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
Acknowledgement sent to Mitch Blevins <mblevin@debian.org>:
Extra info received and forwarded to list. Copy sent to Peter S Galbraith <psg@debian.org>.
-t
From: owner@bugs.debian.org (Debian Bug Tracking System)
To: Mitch Blevins
Subject: Bug#55123: Info received (was I think /etc/init.d/powerfail shouldn't be a conffile)
Message-ID:
In-Reply-To: <20000114203507.A12285@mindspring.com>
References: <20000114203507.A12285@mindspring.com>
X-Debian-PR-Message: ack-info-maintonly 55123
Thank you for the additional information you have supplied regarding
this problem report. It has been forwarded to the developer(s) and
to the developers mailing list to accompany the original report.
Your message has been sent to the package maintainer(s):
Peter S Galbraith
If you wish to continue to submit further information on your problem,
please send it to 55123@bugs.debian.org, as before.
Please do not reply to the address at the top of this message,
unless you wish to report a problem with the Bug-tracking system.
Darren Benham
(administrator, Debian Bugs database)
Received: (at 55123) by bugs.debian.org; 15 Jan 2000 02:29:12 +0000
Received: (qmail 13356 invoked from network); 15 Jan 2000 02:29:11 -0000
Received: from smtp6.mindspring.com (207.69.200.110)
by master.debian.org with SMTP; 15 Jan 2000 02:29:11 -0000
Received: from turd.mountaintop ([209.138.161.173])
by smtp6.mindspring.com (8.9.3/8.8.5) with ESMTP id VAA24780;
Fri, 14 Jan 2000 21:29:09 -0500 (EST)
Received: from mblevin by turd.mountaintop with local (Exim 3.11 #1 (Debian))
id 129I7P-0003CR-00; Fri, 14 Jan 2000 20:35:07 -0500
Date: Fri, 14 Jan 2000 20:35:07 -0500
From: Mitch Blevins
To: Peter S Galbraith
Cc: 55123@bugs.debian.org
Subject: Re: I think /etc/init.d/powerfail shouldn't be a conffile
Message-ID: <20000114203507.A12285@mindspring.com>
Reply-To: Mitch Blevins
References: <200001141714.MAA12742@mixing.qc.dfo.ca>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Mutt/1.0i
In-Reply-To: <200001141714.MAA12742@mixing.qc.dfo.ca>; from GalbraithP@dfo-mpo.gc.ca on Fri, Jan 14, 2000 at 12:14:47PM -0500
Sender: Mitch Blevins
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.
debian-bugs-dist@lists.debian.orgPeter S Galbraith
Subject: Bug#55123: I think /etc/init.d/powerfail shouldn't be a conffile
Reply-To: Peter S Galbraith , 55123@bugs.debian.org
Resent-From: Peter S Galbraith
Resent-To: debian-bugs-dist@lists.debian.org
Resent-CC: Peter S Galbraith
Resent-Date: Sat, 15 Jan 2000 03:03:24 GMT
Resent-Message-ID:
Resent-Sender: owner@bugs.debian.org
X-Debian-PR-Message: report 55123
X-Debian-PR-Package: powstatd
X-Debian-PR-Keywords:
X-Loop: owner@bugs.debian.org
Received: via spool by 55123-bugs@bugs.debian.org id=B55123.9479051991858
(code B ref 55123); Sat, 15 Jan 2000 03:03:24 GMT
Message-Id: <200001150259.VAA15529@mixing.qc.dfo.ca>
To: Mitch Blevins
Cc: 55123@bugs.debian.org, Peter S Galbraith ,
Brian White
In-reply-to: (Your message of Fri, 14 Jan 2000 20:35:07 EST.)
<20000114203507.A12285@mindspring.com>
Date: Fri, 14 Jan 2000 21:59:30 -0500
From: Peter S Galbraith
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 Peter S Galbraith <GalbraithP@dfo-mpo.gc.ca>:
Extra info received and forwarded to list. Copy sent to Peter S Galbraith <psg@debian.org>.
-t
From: owner@bugs.debian.org (Debian Bug Tracking System)
To: Peter S Galbraith
Subject: Bug#55123: Info received (was I think /etc/init.d/powerfail shouldn't be a conffile )
Message-ID:
In-Reply-To: <200001150259.VAA15529@mixing.qc.dfo.ca>
References: <200001150259.VAA15529@mixing.qc.dfo.ca>
X-Debian-PR-Message: ack-info-maintonly 55123
Thank you for the additional information you have supplied regarding
this problem report. It has been forwarded to the developer(s) and
to the developers mailing list to accompany the original report.
Your message has been sent to the package maintainer(s):
Peter S Galbraith
If you wish to continue to submit further information on your problem,
please send it to 55123@bugs.debian.org, as before.
Please do not reply to the address at the top of this message,
unless you wish to report a problem with the Bug-tracking system.
Darren Benham
(administrator, Debian Bugs database)
Received: (at 55123) by bugs.debian.org; 15 Jan 2000 02:59:59 +0000
Received: (qmail 1844 invoked from network); 15 Jan 2000 02:59:58 -0000
Received: from mixing.qc.dfo-mpo.gc.ca (HELO mixing.qc.dfo.ca) (207.216.183.21)
by master.debian.org with SMTP; 15 Jan 2000 02:59:58 -0000
Received: from mixing.qc.dfo.ca (rhogee@localhost [127.0.0.1])
by mixing.qc.dfo.ca (8.9.3/8.8.5) with ESMTP id VAA15529;
Fri, 14 Jan 2000 21:59:31 -0500
Message-Id: <200001150259.VAA15529@mixing.qc.dfo.ca>
To: Mitch Blevins
Cc: 55123@bugs.debian.org, Peter S Galbraith ,
Brian White
Subject: Re: I think /etc/init.d/powerfail shouldn't be a conffile
In-reply-to: (Your message of Fri, 14 Jan 2000 20:35:07 EST.)
<20000114203507.A12285@mindspring.com>
Date: Fri, 14 Jan 2000 21:59:30 -0500
From: Peter S Galbraith
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.
-t
From: owner@bugs.debian.org (Debian Bug Tracking System)
To: Brian White
Subject: Bug#55123: Info received and FILED only
(was I think /etc/init.d/powerfail shouldn't be a conffile)
Message-ID:
In-Reply-To: <38808236.87C4B114@pobox.com>
References: <38808236.87C4B114@pobox.com>
X-Debian-PR-Message: ack-info-quiet 55123
Thank you for the additional information you have supplied regarding
this problem report. It has NOT been forwarded to the developers, but
will accompany the original report in the Bug tracking system. Please
ensure that you yourself have sent a copy of the additional
information to any relevant developers or mailing lists.
If you wish to continue to submit further information on your problem,
please send it to 55123-quiet@bugs.debian.org, as before.
Please do not reply to the address at the top of this message,
unless you wish to report a problem with the Bug-tracking system.
Darren Benham
(administrator, Debian Bugs database)
Received: (at 55123-quiet) by bugs.debian.org; 15 Jan 2000 14:20:48 +0000
Received: (qmail 7743 invoked from network); 15 Jan 2000 14:20:38 -0000
Received: from cpu1612.adsl.bellglobal.com (HELO gatekeeper.bcwhite.dhs.org) (mail@206.47.27.93)
by master.debian.org with SMTP; 15 Jan 2000 14:20:38 -0000
Received: from dragon.bcwhite.dhs.org (pobox.com) [192.168.1.10] (bcwhite)
by gatekeeper.bcwhite.dhs.org with esmtp (Exim 2.05 #1 (Debian))
id 129U4F-0005XE-00; Sat, 15 Jan 2000 09:20:39 -0500
Sender: bcwhite
Message-ID: <38808236.87C4B114@pobox.com>
Date: Sat, 15 Jan 2000 09:20:38 -0500
From: Brian White
X-Mailer: Mozilla 4.5 [en] (X11; U; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Peter S Galbraith ,
Mitch Blevins
CC: 55123-quiet@bugs.debian.org
Subject: Re: I think /etc/init.d/powerfail shouldn't be a conffile
References: <200001141714.MAA12742@mixing.qc.dfo.ca>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
> 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.
-t
From: owner@bugs.debian.org (Debian Bug Tracking System)
To: Peter S Galbraith
Subject: Bug#55123: Info received and FILED only
(was I think /etc/init.d/powerfail shouldn't be a conffile )
Message-ID:
In-Reply-To: <200001151611.LAA18588@mixing.qc.dfo.ca>
References: <200001151611.LAA18588@mixing.qc.dfo.ca>
X-Debian-PR-Message: ack-info-quiet 55123
Thank you for the additional information you have supplied regarding
this problem report. It has NOT been forwarded to the developers, but
will accompany the original report in the Bug tracking system. Please
ensure that you yourself have sent a copy of the additional
information to any relevant developers or mailing lists.
If you wish to continue to submit further information on your problem,
please send it to 55123-quiet@bugs.debian.org, as before.
Please do not reply to the address at the top of this message,
unless you wish to report a problem with the Bug-tracking system.
Darren Benham
(administrator, Debian Bugs database)
Received: (at 55123-quiet) by bugs.debian.org; 15 Jan 2000 16:11:46 +0000
Received: (qmail 13615 invoked from network); 15 Jan 2000 16:11:45 -0000
Received: from mixing.qc.dfo-mpo.gc.ca (HELO mixing.qc.dfo.ca) (207.216.183.21)
by master.debian.org with SMTP; 15 Jan 2000 16:11:45 -0000
Received: from mixing.qc.dfo.ca (rhogee@localhost [127.0.0.1])
by mixing.qc.dfo.ca (8.9.3/8.8.5) with ESMTP id LAA18588;
Sat, 15 Jan 2000 11:11:12 -0500
Message-Id: <200001151611.LAA18588@mixing.qc.dfo.ca>
To: Brian White
cc: Peter S Galbraith ,
Mitch Blevins , 55123-quiet@bugs.debian.org
Subject: Re: I think /etc/init.d/powerfail shouldn't be a conffile
In-reply-to: (Your message of Sat, 15 Jan 2000 09:20:38 EST.)
<38808236.87C4B114@pobox.com>
Date: Sat, 15 Jan 2000 11:11:11 -0500
From: Peter S Galbraith
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.
-t
From: owner@bugs.debian.org (Debian Bug Tracking System)
To: Brian White
Subject: Bug#55123: Info received and FILED only
(was I think /etc/init.d/powerfail shouldn't be a conffile)
Message-ID:
In-Reply-To: <38809FEE.5A3890BD@pobox.com>
References: <38809FEE.5A3890BD@pobox.com>
X-Debian-PR-Message: ack-info-quiet 55123
Thank you for the additional information you have supplied regarding
this problem report. It has NOT been forwarded to the developers, but
will accompany the original report in the Bug tracking system. Please
ensure that you yourself have sent a copy of the additional
information to any relevant developers or mailing lists.
If you wish to continue to submit further information on your problem,
please send it to 55123-quiet@bugs.debian.org, as before.
Please do not reply to the address at the top of this message,
unless you wish to report a problem with the Bug-tracking system.
Darren Benham
(administrator, Debian Bugs database)
Received: (at 55123-quiet) by bugs.debian.org; 15 Jan 2000 16:27:24 +0000
Received: (qmail 19077 invoked from network); 15 Jan 2000 16:27:23 -0000
Received: from cpu1612.adsl.bellglobal.com (HELO gatekeeper.bcwhite.dhs.org) (mail@206.47.27.93)
by master.debian.org with SMTP; 15 Jan 2000 16:27:23 -0000
Received: from dragon.bcwhite.dhs.org (pobox.com) [192.168.1.10] (bcwhite)
by gatekeeper.bcwhite.dhs.org with esmtp (Exim 2.05 #1 (Debian))
id 129W2y-0005rI-00; Sat, 15 Jan 2000 11:27:28 -0500
Sender: bcwhite
Message-ID: <38809FEE.5A3890BD@pobox.com>
Date: Sat, 15 Jan 2000 11:27:26 -0500
From: Brian White
X-Mailer: Mozilla 4.5 [en] (X11; U; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Peter S Galbraith
CC: Mitch Blevins , 55123-quiet@bugs.debian.org
Subject: Re: I think /etc/init.d/powerfail shouldn't be a conffile
References: <200001151611.LAA18588@mixing.qc.dfo.ca>
Content-Type: multipart/mixed;
boundary="------------D3486AC3F2834A3C32C937EF"
This is a multi-part message in MIME format.
--------------D3486AC3F2834A3C32C937EF
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
> > 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.
--------------D3486AC3F2834A3C32C937EF
Content-Type: text/plain; charset=us-ascii;
name="powerfail.rc"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename="powerfail.rc"
#! /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
# Peter S Galbraith
# Mitch Blevins
#
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
--------------D3486AC3F2834A3C32C937EF--
Acknowledgement sent to Mitch Blevins <mblevin@debian.org>:
Extra info received and filed, but not forwarded.
-t
From: owner@bugs.debian.org (Debian Bug Tracking System)
To: Mitch Blevins
Subject: Bug#55123: Info received and FILED only
(was I think /etc/init.d/powerfail shouldn't be a conffile)
Message-ID:
In-Reply-To: <20000115135656.A13238@mindspring.com>
References: <20000115135656.A13238@mindspring.com>
X-Debian-PR-Message: ack-info-quiet 55123
Thank you for the additional information you have supplied regarding
this problem report. It has NOT been forwarded to the developers, but
will accompany the original report in the Bug tracking system. Please
ensure that you yourself have sent a copy of the additional
information to any relevant developers or mailing lists.
If you wish to continue to submit further information on your problem,
please send it to 55123-quiet@bugs.debian.org, as before.
Please do not reply to the address at the top of this message,
unless you wish to report a problem with the Bug-tracking system.
Darren Benham
(administrator, Debian Bugs database)
Received: (at 55123-quiet) by bugs.debian.org; 15 Jan 2000 19:56:00 +0000
Received: (qmail 7725 invoked from network); 15 Jan 2000 19:55:56 -0000
Received: from smtp10.atl.mindspring.net (207.69.200.246)
by master.debian.org with SMTP; 15 Jan 2000 19:55:56 -0000
Received: from turd.mountaintop (pool-209-138-202-224-dlls.grid.net [209.138.202.224])
by smtp10.atl.mindspring.net (8.9.3/8.8.5) with ESMTP id OAA09567;
Sat, 15 Jan 2000 14:50:54 -0500 (EST)
Received: from mblevin by turd.mountaintop with local (Exim 3.11 #1 (Debian))
id 129YNc-0003Si-00; Sat, 15 Jan 2000 13:56:56 -0500
Date: Sat, 15 Jan 2000 13:56:56 -0500
From: Mitch Blevins
To: Brian White
Cc: 55123-quiet@bugs.debian.org, GalbraithP@dfo-mpo.gc.ca
Subject: Re: I think /etc/init.d/powerfail shouldn't be a conffile
Message-ID: <20000115135656.A13238@mindspring.com>
Reply-To: Mitch Blevins
References: <200001151611.LAA18588@mixing.qc.dfo.ca> <38809FEE.5A3890BD@pobox.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Mutt/1.0i
In-Reply-To: <38809FEE.5A3890BD@pobox.com>; from bcwhite@pobox.com on Sat, Jan 15, 2000 at 11:27:26AM -0500
Sender: Mitch Blevins
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.
-t
From: owner@bugs.debian.org (Debian Bug Tracking System)
To: Peter S Galbraith
Subject: Bug#55123: Info received and FILED only
(was I think /etc/init.d/powerfail shouldn't be a conffile )
Message-ID:
In-Reply-To: <200001152140.QAA19193@mixing.qc.dfo.ca>
References: <200001152140.QAA19193@mixing.qc.dfo.ca>
X-Debian-PR-Message: ack-info-quiet 55123
Thank you for the additional information you have supplied regarding
this problem report. It has NOT been forwarded to the developers, but
will accompany the original report in the Bug tracking system. Please
ensure that you yourself have sent a copy of the additional
information to any relevant developers or mailing lists.
If you wish to continue to submit further information on your problem,
please send it to 55123-quiet@bugs.debian.org, as before.
Please do not reply to the address at the top of this message,
unless you wish to report a problem with the Bug-tracking system.
Darren Benham
(administrator, Debian Bugs database)
Received: (at 55123-quiet) by bugs.debian.org; 15 Jan 2000 21:40:39 +0000
Received: (qmail 2573 invoked from network); 15 Jan 2000 21:40:38 -0000
Received: from mixing.qc.dfo-mpo.gc.ca (HELO mixing.qc.dfo.ca) (207.216.183.21)
by master.debian.org with SMTP; 15 Jan 2000 21:40:38 -0000
Received: from mixing.qc.dfo.ca (rhogee@localhost [127.0.0.1])
by mixing.qc.dfo.ca (8.9.3/8.8.5) with ESMTP id QAA19193;
Sat, 15 Jan 2000 16:40:08 -0500
Message-Id: <200001152140.QAA19193@mixing.qc.dfo.ca>
To: Mitch Blevins , Brian White
Cc: 55123-quiet@bugs.debian.org, GalbraithP@dfo-mpo.gc.ca
Subject: Re: I think /etc/init.d/powerfail shouldn't be a conffile
In-reply-to: (Your message of Sat, 15 Jan 2000 13:56:56 EST.)
<20000115135656.A13238@mindspring.com>
Date: Sat, 15 Jan 2000 16:40:08 -0500
From: Peter S Galbraith
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.
-t
From: owner@bugs.debian.org (Debian Bug Tracking System)
To: Peter S Galbraith
Subject: Bug#55123: Info received and FILED only
(was I think /etc/init.d/powerfail shouldn't be a conffile )
Message-ID:
In-Reply-To: <200001160106.UAA19614@mixing.qc.dfo.ca>
References: <200001160106.UAA19614@mixing.qc.dfo.ca>
X-Debian-PR-Message: ack-info-quiet 55123
Thank you for the additional information you have supplied regarding
this problem report. It has NOT been forwarded to the developers, but
will accompany the original report in the Bug tracking system. Please
ensure that you yourself have sent a copy of the additional
information to any relevant developers or mailing lists.
If you wish to continue to submit further information on your problem,
please send it to 55123-quiet@bugs.debian.org, as before.
Please do not reply to the address at the top of this message,
unless you wish to report a problem with the Bug-tracking system.
Darren Benham
(administrator, Debian Bugs database)
Received: (at 55123-quiet) by bugs.debian.org; 16 Jan 2000 01:07:30 +0000
Received: (qmail 30981 invoked from network); 16 Jan 2000 01:07:26 -0000
Received: from mixing.qc.dfo-mpo.gc.ca (HELO mixing.qc.dfo.ca) (207.216.183.21)
by master.debian.org with SMTP; 16 Jan 2000 01:07:26 -0000
Received: from mixing.qc.dfo.ca (rhogee@localhost [127.0.0.1])
by mixing.qc.dfo.ca (8.9.3/8.8.5) with ESMTP id UAA19614;
Sat, 15 Jan 2000 20:06:53 -0500
Message-Id: <200001160106.UAA19614@mixing.qc.dfo.ca>
To: Brian White
cc: Peter S Galbraith ,
Mitch Blevins , 55123-quiet@bugs.debian.org
Subject: Re: I think /etc/init.d/powerfail shouldn't be a conffile
In-reply-to: (Your message of Sat, 15 Jan 2000 11:27:26 EST.)
<38809FEE.5A3890BD@pobox.com>
Date: Sat, 15 Jan 2000 20:06:53 -0500
From: Peter S Galbraith
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.
-t
From: owner@bugs.debian.org (Debian Bug Tracking System)
To: Peter S Galbraith
Subject: Bug#55123: Info received and FILED only
(was I think /etc/init.d/powerfail shouldn't be a conffile )
Message-ID:
In-Reply-To: <200001161538.KAA01515@mixing.qc.dfo.ca>
References: <200001161538.KAA01515@mixing.qc.dfo.ca>
X-Debian-PR-Message: ack-info-quiet 55123
Thank you for the additional information you have supplied regarding
this problem report. It has NOT been forwarded to the developers, but
will accompany the original report in the Bug tracking system. Please
ensure that you yourself have sent a copy of the additional
information to any relevant developers or mailing lists.
If you wish to continue to submit further information on your problem,
please send it to 55123-quiet@bugs.debian.org, as before.
Please do not reply to the address at the top of this message,
unless you wish to report a problem with the Bug-tracking system.
Darren Benham
(administrator, Debian Bugs database)
Received: (at 55123-quiet) by bugs.debian.org; 16 Jan 2000 15:38:59 +0000
Received: (qmail 587 invoked from network); 16 Jan 2000 15:38:58 -0000
Received: from mixing.qc.dfo-mpo.gc.ca (HELO mixing.qc.dfo.ca) (207.216.183.21)
by master.debian.org with SMTP; 16 Jan 2000 15:38:58 -0000
Received: from mixing.qc.dfo.ca (rhogee@localhost [127.0.0.1])
by mixing.qc.dfo.ca (8.9.3/8.8.5) with ESMTP id KAA01515;
Sun, 16 Jan 2000 10:38:17 -0500
Message-Id: <200001161538.KAA01515@mixing.qc.dfo.ca>
To: Brian White
cc: Peter S Galbraith ,
Mitch Blevins , 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
From: Peter S Galbraith
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.
-t
From: owner@bugs.debian.org (Debian Bug Tracking System)
To: Brian White
Subject: Bug#55123: Info received and FILED only
(was I think /etc/init.d/powerfail shouldn't be a conffile)
Message-ID:
In-Reply-To: <3881F7CD.7096BBD6@pobox.com>
References: <3881F7CD.7096BBD6@pobox.com>
X-Debian-PR-Message: ack-info-quiet 55123
Thank you for the additional information you have supplied regarding
this problem report. It has NOT been forwarded to the developers, but
will accompany the original report in the Bug tracking system. Please
ensure that you yourself have sent a copy of the additional
information to any relevant developers or mailing lists.
If you wish to continue to submit further information on your problem,
please send it to 55123-quiet@bugs.debian.org, as before.
Please do not reply to the address at the top of this message,
unless you wish to report a problem with the Bug-tracking system.
Darren Benham
(administrator, Debian Bugs database)
Received: (at 55123-quiet) by bugs.debian.org; 16 Jan 2000 17:01:35 +0000
Received: (qmail 21216 invoked from network); 16 Jan 2000 16:56:21 -0000
Received: from cpu1612.adsl.bellglobal.com (HELO gatekeeper.bcwhite.dhs.org) (mail@206.47.27.93)
by master.debian.org with SMTP; 16 Jan 2000 16:56:21 -0000
Received: from dragon.bcwhite.dhs.org (pobox.com) [192.168.1.10] (bcwhite)
by gatekeeper.bcwhite.dhs.org with esmtp (Exim 2.05 #1 (Debian))
id 129swp-0002cI-00; Sun, 16 Jan 2000 11:54:39 -0500
Sender: bcwhite
Message-ID: <3881F7CD.7096BBD6@pobox.com>
Date: Sun, 16 Jan 2000 11:54:37 -0500
From: Brian White
X-Mailer: Mozilla 4.5 [en] (X11; U; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Peter S Galbraith
CC: Mitch Blevins , 55123-quiet@bugs.debian.org
Subject: Re: I think /etc/init.d/powerfail shouldn't be a conffile
References: <200001160106.UAA19614@mixing.qc.dfo.ca>
Content-Type: multipart/mixed;
boundary="------------2D7F0094F4DD09733B8FE391"
This is a multi-part message in MIME format.
--------------2D7F0094F4DD09733B8FE391
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
> - 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.
--------------2D7F0094F4DD09733B8FE391
Content-Type: text/plain; charset=us-ascii;
name="powerfail.rc"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename="powerfail.rc"
#! /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
# Peter S Galbraith
# Mitch Blevins
#
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
--------------2D7F0094F4DD09733B8FE391
Content-Type: text/plain; charset=us-ascii;
name="genpower.rc"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename="genpower.rc"
#! /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
#
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
--------------2D7F0094F4DD09733B8FE391
Content-Type: text/plain; charset=us-ascii;
name="halt.rc"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename="halt.rc"
#! /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
--------------2D7F0094F4DD09733B8FE391--
Acknowledgement sent to Peter S Galbraith <GalbraithP@dfo-mpo.gc.ca>:
Extra info received and filed, but not forwarded.
-t
From: owner@bugs.debian.org (Debian Bug Tracking System)
To: Peter S Galbraith
Subject: Bug#55123: Info received and FILED only
(was I think /etc/init.d/powerfail shouldn't be a conffile )
Message-ID:
In-Reply-To: <200001162149.QAA02643@mixing.qc.dfo.ca>
References: <200001162149.QAA02643@mixing.qc.dfo.ca>
X-Debian-PR-Message: ack-info-quiet 55123
Thank you for the additional information you have supplied regarding
this problem report. It has NOT been forwarded to the developers, but
will accompany the original report in the Bug tracking system. Please
ensure that you yourself have sent a copy of the additional
information to any relevant developers or mailing lists.
If you wish to continue to submit further information on your problem,
please send it to 55123-quiet@bugs.debian.org, as before.
Please do not reply to the address at the top of this message,
unless you wish to report a problem with the Bug-tracking system.
Darren Benham
(administrator, Debian Bugs database)
Received: (at 55123-quiet) by bugs.debian.org; 16 Jan 2000 21:49:55 +0000
Received: (qmail 2083 invoked from network); 16 Jan 2000 21:49:49 -0000
Received: from mixing.qc.dfo-mpo.gc.ca (HELO mixing.qc.dfo.ca) (207.216.183.21)
by master.debian.org with SMTP; 16 Jan 2000 21:49:49 -0000
Received: from mixing.qc.dfo.ca (rhogee@localhost [127.0.0.1])
by mixing.qc.dfo.ca (8.9.3/8.8.5) with ESMTP id QAA02643;
Sun, 16 Jan 2000 16:49:03 -0500
Message-Id: <200001162149.QAA02643@mixing.qc.dfo.ca>
To: Brian White
cc: Peter S Galbraith ,
Mitch Blevins , 55123-quiet@bugs.debian.org
Subject: Re: I think /etc/init.d/powerfail shouldn't be a conffile
In-reply-to: (Your message of Sun, 16 Jan 2000 11:54:37 EST.)
<3881F7CD.7096BBD6@pobox.com>
Date: Sun, 16 Jan 2000 16:49:02 -0500
From: Peter S Galbraith
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.
-t
From: owner@bugs.debian.org (Debian Bug Tracking System)
To: Peter S Galbraith
Subject: Bug#55123: Info received and FILED only
(was I think /etc/init.d/powerfail shouldn't be a conffile )
Message-ID:
In-Reply-To: <200001170153.UAA02989@mixing.qc.dfo.ca>
References: <200001170153.UAA02989@mixing.qc.dfo.ca>
X-Debian-PR-Message: ack-info-quiet 55123
Thank you for the additional information you have supplied regarding
this problem report. It has NOT been forwarded to the developers, but
will accompany the original report in the Bug tracking system. Please
ensure that you yourself have sent a copy of the additional
information to any relevant developers or mailing lists.
If you wish to continue to submit further information on your problem,
please send it to 55123-quiet@bugs.debian.org, as before.
Please do not reply to the address at the top of this message,
unless you wish to report a problem with the Bug-tracking system.
Darren Benham
(administrator, Debian Bugs database)
Received: (at 55123-quiet) by bugs.debian.org; 17 Jan 2000 01:53:44 +0000
Received: (qmail 20560 invoked from network); 17 Jan 2000 01:53:43 -0000
Received: from mixing.qc.dfo-mpo.gc.ca (HELO mixing.qc.dfo.ca) (207.216.183.21)
by master.debian.org with SMTP; 17 Jan 2000 01:53:43 -0000
Received: from mixing.qc.dfo.ca (rhogee@localhost [127.0.0.1])
by mixing.qc.dfo.ca (8.9.3/8.8.5) with ESMTP id UAA02989;
Sun, 16 Jan 2000 20:53:08 -0500
Message-Id: <200001170153.UAA02989@mixing.qc.dfo.ca>
To: Brian White
cc: Peter S Galbraith ,
Mitch Blevins , 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
From: Peter S Galbraith
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.
-t
From: owner@bugs.debian.org (Debian Bug Tracking System)
To: Brian White
Subject: Bug#55123: Info received and FILED only
(was I think /etc/init.d/powerfail shouldn't be a conffile)
Message-ID:
In-Reply-To: <388456C7.A5697107@pobox.com>
References: <388456C7.A5697107@pobox.com>
X-Debian-PR-Message: ack-info-quiet 55123
Thank you for the additional information you have supplied regarding
this problem report. It has NOT been forwarded to the developers, but
will accompany the original report in the Bug tracking system. Please
ensure that you yourself have sent a copy of the additional
information to any relevant developers or mailing lists.
If you wish to continue to submit further information on your problem,
please send it to 55123-quiet@bugs.debian.org, as before.
Please do not reply to the address at the top of this message,
unless you wish to report a problem with the Bug-tracking system.
Darren Benham
(administrator, Debian Bugs database)
Received: (at 55123-quiet) by bugs.debian.org; 18 Jan 2000 12:04:03 +0000
Received: (qmail 19850 invoked from network); 18 Jan 2000 12:04:03 -0000
Received: from cpu1612.adsl.bellglobal.com (HELO gatekeeper.bcwhite.dhs.org) (mail@206.47.27.93)
by master.debian.org with SMTP; 18 Jan 2000 12:04:03 -0000
Received: from dragon.bcwhite.dhs.org (pobox.com) [192.168.1.10] (bcwhite)
by gatekeeper.bcwhite.dhs.org with esmtp (Exim 2.05 #1 (Debian))
id 12AXMc-0002oD-00; Tue, 18 Jan 2000 07:03:58 -0500
Sender: bcwhite
Message-ID: <388456C7.A5697107@pobox.com>
Date: Tue, 18 Jan 2000 07:04:23 -0500
From: Brian White
X-Mailer: Mozilla 4.5 [en] (X11; U; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Peter S Galbraith
CC: Mitch Blevins , 55123-quiet@bugs.debian.org
Subject: Re: I think /etc/init.d/powerfail shouldn't be a conffile
References: <200001162149.QAA02643@mixing.qc.dfo.ca>
Content-Type: multipart/mixed;
boundary="------------AB1D5D7D43F8CB46899D7B84"
This is a multi-part message in MIME format.
--------------AB1D5D7D43F8CB46899D7B84
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
> > 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"?
--------------AB1D5D7D43F8CB46899D7B84
Content-Type: text/plain; charset=us-ascii;
name="powerfail.rc"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename="powerfail.rc"
#! /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
# Peter S Galbraith
# Mitch Blevins
#
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
--------------AB1D5D7D43F8CB46899D7B84
Content-Type: text/plain; charset=us-ascii;
name="genpower.rc"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename="genpower.rc"
#! /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
#
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
--------------AB1D5D7D43F8CB46899D7B84
Content-Type: text/plain; charset=us-ascii;
name="halt.rc"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename="halt.rc"
#! /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
--------------AB1D5D7D43F8CB46899D7B84--
Acknowledgement sent to Peter S Galbraith <GalbraithP@dfo-mpo.gc.ca>:
Extra info received and filed, but not forwarded.
-t
From: owner@bugs.debian.org (Debian Bug Tracking System)
To: Peter S Galbraith
Subject: Bug#55123: Info received and FILED only
(was I think /etc/init.d/powerfail shouldn't be a conffile )
Message-ID:
In-Reply-To: <200001181515.KAA14528@mixing.qc.dfo.ca>
References: <200001181515.KAA14528@mixing.qc.dfo.ca>
X-Debian-PR-Message: ack-info-quiet 55123
Thank you for the additional information you have supplied regarding
this problem report. It has NOT been forwarded to the developers, but
will accompany the original report in the Bug tracking system. Please
ensure that you yourself have sent a copy of the additional
information to any relevant developers or mailing lists.
If you wish to continue to submit further information on your problem,
please send it to 55123-quiet@bugs.debian.org, as before.
Please do not reply to the address at the top of this message,
unless you wish to report a problem with the Bug-tracking system.
Darren Benham
(administrator, Debian Bugs database)
Received: (at 55123-quiet) by bugs.debian.org; 18 Jan 2000 15:16:02 +0000
Received: (qmail 17448 invoked from network); 18 Jan 2000 15:16:00 -0000
Received: from mixing.qc.dfo-mpo.gc.ca (HELO mixing.qc.dfo.ca) (207.216.183.21)
by master.debian.org with SMTP; 18 Jan 2000 15:16:00 -0000
Received: from mixing.qc.dfo.ca (rhogee@localhost [127.0.0.1])
by mixing.qc.dfo.ca (8.9.3/8.8.5) with ESMTP id KAA14528;
Tue, 18 Jan 2000 10:15:16 -0500
Message-Id: <200001181515.KAA14528@mixing.qc.dfo.ca>
To: Brian White
cc: Peter S Galbraith ,
Mitch Blevins , 55123-quiet@bugs.debian.org
Subject: Re: I think /etc/init.d/powerfail shouldn't be a conffile
In-reply-to: (Your message of Tue, 18 Jan 2000 07:04:23 EST.)
<388456C7.A5697107@pobox.com>
Date: Tue, 18 Jan 2000 10:15:16 -0500
From: Peter S Galbraith
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.
-t
From: owner@bugs.debian.org (Debian Bug Tracking System)
To: Peter S Galbraith
Subject: Bug#55123: Info received and FILED only
(was Simplifying halt script a tad more.)
Message-ID:
In-Reply-To: <200001181802.NAA15179@mixing.qc.dfo.ca>
References: <200001181802.NAA15179@mixing.qc.dfo.ca>
X-Debian-PR-Message: ack-info-quiet 55123
Thank you for the additional information you have supplied regarding
this problem report. It has NOT been forwarded to the developers, but
will accompany the original report in the Bug tracking system. Please
ensure that you yourself have sent a copy of the additional
information to any relevant developers or mailing lists.
If you wish to continue to submit further information on your problem,
please send it to 55123-quiet@bugs.debian.org, as before.
Please do not reply to the address at the top of this message,
unless you wish to report a problem with the Bug-tracking system.
Darren Benham
(administrator, Debian Bugs database)
Received: (at 55123-quiet) by bugs.debian.org; 18 Jan 2000 18:03:15 +0000
Received: (qmail 13242 invoked from network); 18 Jan 2000 18:03:12 -0000
Received: from mixing.qc.dfo-mpo.gc.ca (HELO mixing.qc.dfo.ca) (207.216.183.21)
by master.debian.org with SMTP; 18 Jan 2000 18:03:12 -0000
Received: from mixing.qc.dfo.ca (rhogee@localhost [127.0.0.1])
by mixing.qc.dfo.ca (8.9.3/8.8.5) with ESMTP id NAA15179;
Tue, 18 Jan 2000 13:02:38 -0500
Message-Id: <200001181802.NAA15179@mixing.qc.dfo.ca>
To: Brian White
cc: Peter S Galbraith ,
Mitch Blevins , 55123-quiet@bugs.debian.org
Subject: Simplifying halt script a tad more.
In-reply-to: (Your message of Tue, 18 Jan 2000 07:04:23 EST.)
<388456C7.A5697107@pobox.com>
Date: Tue, 18 Jan 2000 13:02:37 -0500
From: Peter S Galbraith
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.
-t
From: owner@bugs.debian.org (Debian Bug Tracking System)
To: Peter S Galbraith
Subject: Bug#55123: Info received and FILED only
(was Simplifying halt script a tad more)
Message-ID:
In-Reply-To: <200001181838.NAA15384@mixing.qc.dfo.ca>
References: <200001181838.NAA15384@mixing.qc.dfo.ca>
X-Debian-PR-Message: ack-info-quiet 55123
Thank you for the additional information you have supplied regarding
this problem report. It has NOT been forwarded to the developers, but
will accompany the original report in the Bug tracking system. Please
ensure that you yourself have sent a copy of the additional
information to any relevant developers or mailing lists.
If you wish to continue to submit further information on your problem,
please send it to 55123-quiet@bugs.debian.org, as before.
Please do not reply to the address at the top of this message,
unless you wish to report a problem with the Bug-tracking system.
Darren Benham
(administrator, Debian Bugs database)
Received: (at 55123-quiet) by bugs.debian.org; 18 Jan 2000 18:39:11 +0000
Received: (qmail 32331 invoked from network); 18 Jan 2000 18:39:09 -0000
Received: from mixing.qc.dfo-mpo.gc.ca (HELO mixing.qc.dfo.ca) (207.216.183.21)
by master.debian.org with SMTP; 18 Jan 2000 18:39:09 -0000
Received: from mixing.qc.dfo.ca (rhogee@localhost [127.0.0.1])
by mixing.qc.dfo.ca (8.9.3/8.8.5) with ESMTP id NAA15384;
Tue, 18 Jan 2000 13:38:15 -0500
Message-Id: <200001181838.NAA15384@mixing.qc.dfo.ca>
To: Brian White
cc: Peter S Galbraith ,
Mitch Blevins , 55123-quiet@bugs.debian.org
Subject: Simplifying halt script a tad more
Date: Tue, 18 Jan 2000 13:38:14 -0500
From: Peter S Galbraith
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.
-t
From: owner@bugs.debian.org (Debian Bug Tracking System)
To: Peter S Galbraith
Subject: Bug#55123: Info received and FILED only
(was Simplifying halt script a tad more)
Message-ID:
In-Reply-To: <200001182005.PAA00315@mixing.qc.dfo.ca>
References: <200001182005.PAA00315@mixing.qc.dfo.ca>
X-Debian-PR-Message: ack-info-quiet 55123
Thank you for the additional information you have supplied regarding
this problem report. It has NOT been forwarded to the developers, but
will accompany the original report in the Bug tracking system. Please
ensure that you yourself have sent a copy of the additional
information to any relevant developers or mailing lists.
If you wish to continue to submit further information on your problem,
please send it to 55123-quiet@bugs.debian.org, as before.
Please do not reply to the address at the top of this message,
unless you wish to report a problem with the Bug-tracking system.
Darren Benham
(administrator, Debian Bugs database)
Received: (at 55123-quiet) by bugs.debian.org; 18 Jan 2000 20:05:50 +0000
Received: (qmail 23579 invoked from network); 18 Jan 2000 20:05:39 -0000
Received: from mixing.qc.dfo-mpo.gc.ca (HELO mixing.qc.dfo.ca) (207.216.183.21)
by master.debian.org with SMTP; 18 Jan 2000 20:05:39 -0000
Received: from mixing.qc.dfo.ca (rhogee@localhost [127.0.0.1])
by mixing.qc.dfo.ca (8.9.3/8.8.5) with ESMTP id PAA00315;
Tue, 18 Jan 2000 15:05:05 -0500
Message-Id: <200001182005.PAA00315@mixing.qc.dfo.ca>
To: Brian White
cc: Peter S Galbraith ,
Mitch Blevins , 55123-quiet@bugs.debian.org
Subject: Simplifying halt script a tad more
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----- =_aaaaaaaaaa0"
Content-ID: <310.948225819.0@mixing.qc.dfo.ca>
Date: Tue, 18 Jan 2000 15:05:05 -0500
From: Peter S Galbraith
------- =_aaaaaaaaaa0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <310.948225819.1@mixing.qc.dfo.ca>
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
------- =_aaaaaaaaaa0
Content-Type: text/plain; name="halt"; charset="us-ascii"
Content-ID: <310.948225819.2@mixing.qc.dfo.ca>
#! /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
------- =_aaaaaaaaaa0
Content-Type: text/plain; name="powerfail"; charset="us-ascii"
Content-ID: <310.948225819.3@mixing.qc.dfo.ca>
#! /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
# Peter S Galbraith
# Mitch Blevins
#
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
------- =_aaaaaaaaaa0
Content-Type: text/plain; name="ups-monitor"; charset="us-ascii"
Content-ID: <310.948225819.4@mixing.qc.dfo.ca>
#! /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 .
# Modified for Debian GNU/Linux
# by Ian Murdock .
#
# Version: @(#)skeleton 1.6 11-Nov-1996 miquels@cistron.nl
#
# This file by Peter S Galbraith 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
------- =_aaaaaaaaaa0--
Acknowledgement sent to Brian White <bcwhite@pobox.com>:
Extra info received and filed, but not forwarded.
-t
From: owner@bugs.debian.org (Debian Bug Tracking System)
To: Brian White
Subject: Bug#55123: Info received and FILED only
(was I think /etc/init.d/powerfail shouldn't be a conffile)
Message-ID:
In-Reply-To: <388532CC.FDD23D31@pobox.com>
References: <388532CC.FDD23D31@pobox.com>
X-Debian-PR-Message: ack-info-quiet 55123
Thank you for the additional information you have supplied regarding
this problem report. It has NOT been forwarded to the developers, but
will accompany the original report in the Bug tracking system. Please
ensure that you yourself have sent a copy of the additional
information to any relevant developers or mailing lists.
If you wish to continue to submit further information on your problem,
please send it to 55123-quiet@bugs.debian.org, as before.
Please do not reply to the address at the top of this message,
unless you wish to report a problem with the Bug-tracking system.
Darren Benham
(administrator, Debian Bugs database)
Received: (at 55123-quiet) by bugs.debian.org; 19 Jan 2000 03:42:27 +0000
Received: (qmail 1027 invoked from network); 19 Jan 2000 03:42:27 -0000
Received: from cpu1612.adsl.bellglobal.com (HELO gatekeeper.bcwhite.dhs.org) (mail@206.47.27.93)
by master.debian.org with SMTP; 19 Jan 2000 03:42:27 -0000
Received: from dragon.bcwhite.dhs.org (pobox.com) [192.168.1.10] (bcwhite)
by gatekeeper.bcwhite.dhs.org with esmtp (Exim 2.05 #1 (Debian))
id 12Am14-0006fU-00; Tue, 18 Jan 2000 22:42:42 -0500
Sender: bcwhite
Message-ID: <388532CC.FDD23D31@pobox.com>
Date: Tue, 18 Jan 2000 22:43:08 -0500
From: Brian White
X-Mailer: Mozilla 4.5 [en] (X11; U; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Peter S Galbraith
CC: Mitch Blevins , 55123-quiet@bugs.debian.org
Subject: Re: I think /etc/init.d/powerfail shouldn't be a conffile
References: <200001181515.KAA14528@mixing.qc.dfo.ca>
Content-Type: multipart/mixed;
boundary="------------32E1F8E106C0AFB9C80196E3"
This is a multi-part message in MIME format.
--------------32E1F8E106C0AFB9C80196E3
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
> > 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
--------------32E1F8E106C0AFB9C80196E3
Content-Type: text/plain; charset=us-ascii;
name="powerfail.rc"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename="powerfail.rc"
#! /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
# Peter S Galbraith
# Mitch Blevins
#
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
--------------32E1F8E106C0AFB9C80196E3
Content-Type: text/plain; charset=us-ascii;
name="halt.rc"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename="halt.rc"
#! /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
--------------32E1F8E106C0AFB9C80196E3
Content-Type: text/plain; charset=us-ascii;
name="genpower.rc"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename="genpower.rc"
#! /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
#
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
--------------32E1F8E106C0AFB9C80196E3--
Acknowledgement sent to Peter S Galbraith <GalbraithP@dfo-mpo.gc.ca>:
Extra info received and filed, but not forwarded.
-t
From: owner@bugs.debian.org (Debian Bug Tracking System)
To: Peter S Galbraith
Subject: Bug#55123: Info received and FILED only
(was I think /etc/init.d/powerfail shouldn't be a conffile )
Message-ID:
In-Reply-To: <200001190400.XAA02040@mixing.qc.dfo.ca>
References: <200001190400.XAA02040@mixing.qc.dfo.ca>
X-Debian-PR-Message: ack-info-quiet 55123
Thank you for the additional information you have supplied regarding
this problem report. It has NOT been forwarded to the developers, but
will accompany the original report in the Bug tracking system. Please
ensure that you yourself have sent a copy of the additional
information to any relevant developers or mailing lists.
If you wish to continue to submit further information on your problem,
please send it to 55123-quiet@bugs.debian.org, as before.
Please do not reply to the address at the top of this message,
unless you wish to report a problem with the Bug-tracking system.
Darren Benham
(administrator, Debian Bugs database)
Received: (at 55123-quiet) by bugs.debian.org; 19 Jan 2000 04:01:12 +0000
Received: (qmail 4143 invoked from network); 19 Jan 2000 04:01:10 -0000
Received: from mixing.qc.dfo-mpo.gc.ca (HELO mixing.qc.dfo.ca) (207.216.183.21)
by master.debian.org with SMTP; 19 Jan 2000 04:01:10 -0000
Received: from mixing.qc.dfo.ca (rhogee@localhost [127.0.0.1])
by mixing.qc.dfo.ca (8.9.3/8.8.5) with ESMTP id XAA02040;
Tue, 18 Jan 2000 23:00:38 -0500
Message-Id: <200001190400.XAA02040@mixing.qc.dfo.ca>
To: Brian White
cc: Peter S Galbraith ,
Mitch Blevins , 55123-quiet@bugs.debian.org
Subject: Re: I think /etc/init.d/powerfail shouldn't be a conffile
In-reply-to: (Your message of Tue, 18 Jan 2000 22:43:08 EST.)
<388532CC.FDD23D31@pobox.com>
Date: Tue, 18 Jan 2000 23:00:37 -0500
From: Peter S Galbraith
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.
-t
From: owner@bugs.debian.org (Debian Bug Tracking System)
To: Brian White
Subject: Bug#55123: Info received and FILED only
(was I think /etc/init.d/powerfail shouldn't be a conffile)
Message-ID:
In-Reply-To: <3885AF5D.D00EC6AE@pobox.com>
References: <3885AF5D.D00EC6AE@pobox.com>
X-Debian-PR-Message: ack-info-quiet 55123
Thank you for the additional information you have supplied regarding
this problem report. It has NOT been forwarded to the developers, but
will accompany the original report in the Bug tracking system. Please
ensure that you yourself have sent a copy of the additional
information to any relevant developers or mailing lists.
If you wish to continue to submit further information on your problem,
please send it to 55123-quiet@bugs.debian.org, as before.
Please do not reply to the address at the top of this message,
unless you wish to report a problem with the Bug-tracking system.
Darren Benham
(administrator, Debian Bugs database)
Received: (at 55123-quiet) by bugs.debian.org; 19 Jan 2000 12:34:17 +0000
Received: (qmail 4552 invoked from network); 19 Jan 2000 12:34:17 -0000
Received: from cpu1612.adsl.bellglobal.com (HELO gatekeeper.bcwhite.dhs.org) (mail@206.47.27.93)
by master.debian.org with SMTP; 19 Jan 2000 12:34:17 -0000
Received: from dragon.bcwhite.dhs.org (pobox.com) [192.168.1.10] (bcwhite)
by gatekeeper.bcwhite.dhs.org with esmtp (Exim 2.05 #1 (Debian))
id 12AuJQ-0000GV-00; Wed, 19 Jan 2000 07:34:12 -0500
Sender: bcwhite
Message-ID: <3885AF5D.D00EC6AE@pobox.com>
Date: Wed, 19 Jan 2000 07:34:37 -0500
From: Brian White
X-Mailer: Mozilla 4.5 [en] (X11; U; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Peter S Galbraith
CC: Mitch Blevins , 55123-quiet@bugs.debian.org
Subject: Re: I think /etc/init.d/powerfail shouldn't be a conffile
References: <200001190400.XAA02040@mixing.qc.dfo.ca>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
> > > 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.
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.
-t
From: owner@bugs.debian.org (Debian Bug Tracking System)
To: Brian White
Subject: Bug#55123: Info received and FILED only
(was Improved sysvinit UPS support)
Message-ID:
In-Reply-To: <3885B423.125523F7@pobox.com>
References: <3885B423.125523F7@pobox.com>
X-Debian-PR-Message: ack-info-quiet 55123
Thank you for the additional information you have supplied regarding
this problem report. It has NOT been forwarded to the developers, but
will accompany the original report in the Bug tracking system. Please
ensure that you yourself have sent a copy of the additional
information to any relevant developers or mailing lists.
If you wish to continue to submit further information on your problem,
please send it to 55123-quiet@bugs.debian.org, as before.
Please do not reply to the address at the top of this message,
unless you wish to report a problem with the Bug-tracking system.
Darren Benham
(administrator, Debian Bugs database)
Received: (at 55123-quiet) by bugs.debian.org; 19 Jan 2000 12:54:38 +0000
Received: (qmail 8332 invoked from network); 19 Jan 2000 12:54:37 -0000
Received: from cpu1612.adsl.bellglobal.com (HELO gatekeeper.bcwhite.dhs.org) (mail@206.47.27.93)
by master.debian.org with SMTP; 19 Jan 2000 12:54:37 -0000
Received: from dragon.bcwhite.dhs.org (pobox.com) [192.168.1.10] (bcwhite)
by gatekeeper.bcwhite.dhs.org with esmtp (Exim 2.05 #1 (Debian))
id 12Aud6-0000Kn-00; Wed, 19 Jan 2000 07:54:32 -0500
Sender: bcwhite
Message-ID: <3885B423.125523F7@pobox.com>
Date: Wed, 19 Jan 2000 07:54:59 -0500
From: Brian White
X-Mailer: Mozilla 4.5 [en] (X11; U; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Miquel van Smoorenburg
CC: Peter S Galbraith ,
Mitch Blevins , 55123-quiet@bugs.debian.org
Subject: Improved sysvinit UPS support
References: <200001190400.XAA02040@mixing.qc.dfo.ca>
Content-Type: multipart/mixed;
boundary="------------8752E30A48A5B3D8E7852002"
This is a multi-part message in MIME format.
--------------8752E30A48A5B3D8E7852002
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
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.
--------------8752E30A48A5B3D8E7852002
Content-Type: text/plain; charset=us-ascii;
name="powerfail.rc"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename="powerfail.rc"
#! /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
# Peter S Galbraith
# Mitch Blevins
#
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
--------------8752E30A48A5B3D8E7852002
Content-Type: text/plain; charset=us-ascii;
name="halt.rc"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename="halt.rc"
#! /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