Bug 346271 - halt initscript does not properly handle apcupsd shutdowns
halt initscript does not properly handle apcupsd shutdowns
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: apcupsd (Show other bugs)
15
All Linux
low Severity low
: ---
: ---
Assigned To: Michal Hlavinka
Fedora Extras Quality Assurance
: Patch
Depends On: 474473 474474
Blocks:
  Show dependency treegraph
 
Reported: 2007-10-23 01:18 EDT by David Shaw
Modified: 2011-07-08 13:59 EDT (History)
11 users (show)

See Also:
Fixed In Version: apcupsd-3.14.8-8.fc15
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-07-08 13:59:38 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
A patch for /etc/rc.d/init.d/halt (293 bytes, patch)
2007-10-23 01:26 EDT, David Shaw
no flags Details | Diff
Patch in diff -u format (537 bytes, patch)
2007-10-23 13:35 EDT, David Shaw
no flags Details | Diff
Patch for halt (55 bytes, text/plain)
2009-04-24 17:23 EDT, Matt Castelein
no flags Details
Patch for halt (986 bytes, patch)
2009-04-24 17:25 EDT, Matt Castelein
no flags Details | Diff

  None (edit)
Description David Shaw 2007-10-23 01:18:53 EDT
Description of problem:

When using the apcupsd package, if there is a power outage, the apcupsd daemon
signals the system that it needs to have the UPS powered off.  The halt
initscript on Fedora is missing the instructions to check for this (the
instructions are present only for 'nut', a different UPS management package).

Version-Release number of selected component (if applicable):

initscripts-8.54.1-1

Steps to Reproduce:
1. While using apcupsd, cause a power failure (pull the plug)
2. Note that the UPS never shuts off
Comment 1 David Shaw 2007-10-23 01:26:17 EDT
Created attachment 234771 [details]
A patch for /etc/rc.d/init.d/halt

Here's one way to fix it.
Comment 2 Bill Nottingham 2007-10-23 13:20:19 EDT
Can you add a patch in 'diff -u' format?
Comment 3 David Shaw 2007-10-23 13:35:10 EDT
Created attachment 235301 [details]
Patch in diff -u format

Oops, sorry.  Here's a diff -u patch.
Comment 4 Vadym Chepkov 2008-02-14 11:18:32 EST
The patch won't work if /usr is a separate filesystem, which will be unmounted 
at this point.

Comment 5 David Shaw 2008-02-14 11:46:41 EST
That's a good point.  The new code is just this:

 if [ -f /etc/apcupsd/powerfail ]; then
    echo "APCUPSD will shortly power off the UPS."
    /etc/apcupsd/apccontrol killpower
    echo "Please ensure that the UPS has powered off before rebooting."
    echo "Otherwise, the UPS may cut the power during the reboot!"
 fi

But it must happen before the unmounts.
Comment 6 Vadym Chepkov 2008-02-14 12:34:33 EST
It could be dangerous, unmounting may take awhile and to lose power before file 
systems were unmounted is not a good idea.
The proper solution would be to move apcupsd into /sbin. nut package (Network 
UPS Tools) has essential parts in /sbin, I don't see why apcupsd can't have the 
same
Comment 7 Vadym Chepkov 2008-02-14 12:50:45 EST
One more note. Some people get frustrated when package behavior changes 
suddenly, I know I am. So maybe this change should 
introduce /etc/sysconfig/apcupsd with default value KILLPOWER=no and only if it 
is set to "yes" turn off the ups. That can be useful in situations when apcupsd 
is network slave as well.
Comment 8 Matt Castelein 2008-02-15 11:21:34 EST
You can add this to your halt script to power off the UPS and ensure the machine
halts but stays running until the UPS cuts power, this way it will power back on
when the mains come on line.  This is the script I use:

# See if this is a powerfail situation.
if [ -f /etc/apcupsd/powerfail ]; then
   echo
   echo "APCUPSD will now power off the UPS"
   echo
   /etc/apcupsd/apccontrol killpower
   echo
   echo "Please ensure that the UPS has powered off before rebooting"
   echo "Otherwise, the UPS may cut the power during the reboot!!!"
   echo
   /sbin/halt -d -h -i
else
   # First, try kexec. If that fails, fall back to rebooting the old way.
   [ -n "$kexec_command" ] && $kexec_command -e -x >& /dev/null

   HALTARGS="-d"
   [ -f /poweroff -o ! -f /halt ] && HALTARGS="$HALTARGS -p"

   exec $command $HALTARGS
fi
Comment 9 Bug Zapper 2008-05-14 10:49:59 EDT
This message is a reminder that Fedora 7 is nearing the end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 7. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '7'.

Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 7's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 7 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug. If you are unable to change the version, please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. If possible, it is recommended that you try the newest available Fedora distribution to see if your bug still exists.

Please read the Release Notes for the newest Fedora distribution to make sure it will meet your needs:
http://docs.fedoraproject.org/release-notes/

The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 10 Nerijus Baliūnas 2008-05-27 20:02:13 EDT
(In reply to comment #6)
> It could be dangerous, unmounting may take awhile and to lose power before file 
> systems were unmounted is not a good idea.
> The proper solution would be to move apcupsd into /sbin. nut package (Network 
> UPS Tools) has essential parts in /sbin, I don't see why apcupsd can't have the 
> same

apcupsd original spec file has --sbindir=/sbin as a configure switch:
%configure \
        --prefix=%{_prefix} \
        --sbindir=/sbin \
        --sysconfdir=%{_sysconfdir}/apcupsd \
...

I suggest doing the same here.
Comment 11 Tomas Smetana 2008-06-06 06:11:03 EDT
I've built new version for rawhide that has the binaries in /sbin
Comment 12 Vadym Chepkov 2008-12-02 06:22:50 EST
Unfortunately the problem still exists in Fedora-10

$ ldd /sbin/apcupsd
        linux-gate.so.1 =>  (0x00130000)
        libwrap.so.0 => /lib/libwrap.so.0 (0x00133000)
        libpthread.so.0 => /lib/libpthread.so.0 (0x0013c000)
        libcrypto.so.7 => /lib/libcrypto.so.7 (0x00156000)
        libnetsnmp.so.15 => /usr/lib/libnetsnmp.so.15 (0x002a4000)
        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00362000)
        libc.so.6 => /lib/libc.so.6 (0x00370000)
        /lib/ld-linux.so.2 (0x00110000)
        libnsl.so.1 => /lib/libnsl.so.1 (0x004e4000)
        libdl.so.2 => /lib/libdl.so.2 (0x004fe000)
        libz.so.1 => /lib/libz.so.1 (0x00503000)
        libsensors.so.4 => /usr/lib/libsensors.so.4 (0x00517000)
        libm.so.6 => /lib/libm.so.6 (0x00525000)

as you can see apcupsd relies on libraries that are in /usr and it can be unmounted at this point.
Comment 13 Bill Nottingham 2008-12-02 12:33:22 EST
That would need to be fixed in apcupsd.
Comment 14 David Shaw 2008-12-03 17:43:52 EST
I have opened bug 474473 (lm_sensors) and bug 474474 (net-snmp) to address the library issues.
Comment 15 Bill Nottingham 2008-12-04 09:43:40 EST
I'm not sure lm_sensors or net-snmp really need moved for this - would it be simpler to link them statically? (Not that that's *that* much better).
Comment 16 David Shaw 2008-12-04 12:17:00 EST
I'm happy with either solution.  I do like the simplicity of a static link though.

--- apcupsd-3.14.4/src/Makefile.orig	2008-12-04 12:13:27.000000000 -0500
+++ apcupsd-3.14.4/src/Makefile	2008-12-04 12:12:57.000000000 -0500
@@ -27,7 +27,7 @@
 all-targets: apcupsd apcaccess apctest smtp $(POWERFLUTE)
 
 apcupsd: $(common_obj) $(apcupsd_obj) $(APCDRVLIBS) $(APCLIBS)
-	$(LINK) $(DRVLIBS)
+	$(LINK) -static $(DRVLIBS)
 
 apctest: $(common_obj) $(apctest_obj) $(APCDRVLIBS) $(APCLIBS)
 	$(LINK) $(DRVLIBS)
Comment 17 Matt Castelein 2009-04-24 17:23:20 EDT
Created attachment 341252 [details]
Patch for halt

This is the patch I use for halt and it works well for me.
Comment 18 Matt Castelein 2009-04-24 17:25:48 EDT
Created attachment 341253 [details]
Patch for halt

This is the patch I use for halt and it works well for me.
Comment 19 Matt Castelein 2009-06-16 14:16:22 EDT
Still a problem in initscripts-8.95-1.x86_64 with Fedora 11.
Comment 20 Matt Castelein 2009-06-24 15:44:31 EDT
I feel this should have a severity other than 'low' since it essentially prevents apcupsd from functioning as designed.
Comment 21 Michal Hlavinka 2009-08-04 06:45:48 EDT
I've asked fesco for exception in static linking:

https://fedorahosted.org/fesco/ticket/235
Comment 22 Trevor Cordes 2009-08-06 00:54:19 EDT
"Me too".  I've been using similar halt script patches as suggested in apcupsd docs to make mine work and it *seemed* to work the other day when I had an extended outage.  Of course, the final killpower may have been the UPS actually hitting its hard battery limit and killing, vs software killing.  There was at least 1-2 mins between when the screen said "will now power off the UPS" and when it actually shut off (SUA1500).  Hmm, this may explain why some (remote) boxes I administer sometimes don't seem to kick back on after an outage.  Without killpower working you have that pathological case where the power comes back right when the killpower would have executed.

The apcupsd team is pretty responsive, has anyone tried to open a ticket there?  Perhaps a better solution is an additional program to apccontrol, say /sbin/apckillpower, which has solely this kill function in it and none of the snmp or lm_sensors dependencies.  Might be pretty simple to whip up such a new program (lots of cutting & pasting).

Comment #8 (Matt), your extra step to "ensure the machine halts but stays running until the UPS cuts power" is unnecessary if your BIOS has a "power after power fail" "always on" option.  Your step is only required if your BIOS only has the "last state" option.  In general with UPSs you *always* want the "always on" option.
Comment 23 Michal Hlavinka 2009-08-07 01:54:09 EDT
(In reply to comment #22)
> The apcupsd team is pretty responsive, has anyone tried to open a ticket there?

unfortunately I have different experience :(

>  Perhaps a better solution is an additional program to apccontrol, say
> /sbin/apckillpower, which has solely this kill function in it and none of the
> snmp or lm_sensors dependencies.  Might be pretty simple to whip up such a new
> program (lots of cutting & pasting).

I'll try to ask them if it'd work and if they are willing to do this
Comment 24 Michal Hlavinka 2009-08-21 07:08:24 EDT
bad news, fesco has disapproved static linking of apcupsd with explanation that separate /usr is not supported. But working init script for cases where /usr is not a separated partition is still needed.
Comment 25 Kevin Verma 2009-10-24 16:29:20 EDT
(In reply to comment #16)
> I'm happy with either solution.  I do like the simplicity of a static link
> though.
> 
> --- apcupsd-3.14.4/src/Makefile.orig 2008-12-04 12:13:27.000000000 -0500
> +++ apcupsd-3.14.4/src/Makefile 2008-12-04 12:12:57.000000000 -0500
> @@ -27,7 +27,7 @@
>  all-targets: apcupsd apcaccess apctest smtp $(POWERFLUTE)
> 
>  apcupsd: $(common_obj) $(apcupsd_obj) $(APCDRVLIBS) $(APCLIBS)
> - $(LINK) $(DRVLIBS)
> + $(LINK) -static $(DRVLIBS)
> 
>  apctest: $(common_obj) $(apctest_obj) $(APCDRVLIBS) $(APCLIBS)
>   $(LINK) $(DRVLIBS)  

I tried building a static rpm like in this comment, but it kept failing to build. Can someone guide me if following patch I used is enough. 

<snip>
--- apcupsd-3.14.7/src/Makefile 2009-08-01 17:31:59.000000000 +0530
+++ apcupsd-3.14.7p/src/Makefile        2009-09-17 05:09:04.742907034 +0530
@@ -24,11 +24,9 @@
 
 all-targets: apcupsd apcaccess apctest smtp 
 
-apcupsd: $(common_obj) $(apcupsd_obj) $(APCDRVLIBS) $(APCLIBS)
-       $(LINK) $(DRVLIBS)
-
 apctest: $(common_obj) $(apctest_obj) $(APCDRVLIBS) $(APCLIBS)
-       $(LINK) $(DRVLIBS)
+#      $(LINK) $(DRVLIBS)
+       $(LINK) -static $(DRVLIBS)
 
 apcaccess: $(apcaccess_obj) $(APCLIBS)
        $(LINK)
</snip>

currently its failing with the errors on http://pastebin.com/d72ab0e84
Comment 26 Kevin Verma 2009-10-24 16:31:03 EDT
(In reply to comment #25)

> currently its failing with the errors on http://pastebin.com/d72ab0e84  
previous pastebin url had a life of just one day iirc, so here is one that should live forever http://pastebin.com/f101eee52
Comment 27 Adam Kropelin 2009-10-26 19:53:19 EDT
On the apcupsd side I've recently undertaken to solve the net-snmp issue by writing a new SNMP module that does not require net-snmp at all. Thus no more worries about having libnetsnmp.so available during shutdown. The driver is in the testing phases now and I'd welcome any feedback you might have. For details, see the release announcement here: <http://www.nabble.com/New-SNMP-driver-%28testers-needed%29-td26051600.html> All major features are implemented now, including killpower, trap catching, and commlost detection/recovery (they were not ready at the time of the announcement).

Please join the apcupsd-users mailing list and post any feedback you have, issues encountered, etc.
Comment 28 Bug Zapper 2009-11-18 07:22:25 EST
This message is a reminder that Fedora 10 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 10.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '10'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 10's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 10 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 29 Matt Castelein 2009-11-18 10:02:56 EST
Someone please update the version for this bug to 11 so it doesn't get tossed.
Comment 30 Bug Zapper 2010-04-27 07:47:58 EDT
This message is a reminder that Fedora 11 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 11.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '11'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 11's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 11 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 31 Bug Zapper 2011-06-02 14:37:52 EDT
This message is a reminder that Fedora 13 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 13.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '13'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 13's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 13 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 32 Robert K. Moniot 2011-06-02 15:50:11 EDT
Problem continues in Fedora 14.  /sbin/apcupsd still has dependencies on shared libs in /usr:
# uname -r
2.6.35.12-90.fc14.x86_64
# ldd /sbin/apcupsd 
        linux-vdso.so.1 =>  (0x00007fff8e84b000)
        libwrap.so.0 => /lib64/libwrap.so.0 (0x0000003608600000)
        libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x0000003604000000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x00000035f9c00000)
        libcrypto.so.10 => /lib64/libcrypto.so.10 (0x00000033ef800000)
        libnetsnmp.so.20 => /usr/lib64/libnetsnmp.so.20 (0x00000033efc00000)
        libc.so.6 => /lib64/libc.so.6 (0x00000035f9400000)
        libnsl.so.1 => /lib64/libnsl.so.1 (0x000000360a400000)
        libm.so.6 => /lib64/libm.so.6 (0x00000035f9800000)
        /lib64/ld-linux-x86-64.so.2 (0x00000035f9000000)
        libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00000035fac00000)
        libdl.so.2 => /lib64/libdl.so.2 (0x00000035fa000000)
        libz.so.1 => /lib64/libz.so.1 (0x00000035fa800000)

And /etc/halt does not have instructions to run apcupsd to kill power.

Someone should roll the Fedora version number of this bug to 14.
Comment 33 Bill Nottingham 2011-06-02 16:05:50 EDT
Note that apcupsd can integrate with halt.local if it needs to for Fedora <=15. Given the switch to systemd in Fedora 15, and the fact that /etc/init.d/halt isn't used there, this is unlikely to be changed in initscripts for Fedora 14.

Moving to apcupsd for the linking issue.
Comment 34 Michal Hlavinka 2011-06-16 07:43:19 EDT
Q:MODIFIED, so what is "fixed" ? 
A:Just the problem from bug summary - systemd calls script for UPS shutdown now. 

Q:Will it work with separate /usr partition?
A:No, apcupsd still needs :
        libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x0000003afbe00000)
        libnetsnmp.so.25 => /usr/lib64/libnetsnmp.so.25 (0x0000003afaa00000)
        libssl.so.10 => /usr/lib64/libssl.so.10 (0x0000003b03600000)
Comment 35 Michal Hlavinka 2011-06-16 08:05:29 EDT
The second issue (/usr partition) won't be fixed, because it'd require static linking which is forbidden and exception for apcupsd was declined by fesco, see:
https://fedorahosted.org/fesco/ticket/235
Comment 36 Fedora Update System 2011-06-16 08:26:44 EDT
apcupsd-3.14.8-8.fc15 has been submitted as an update for Fedora 15.
https://admin.fedoraproject.org/updates/apcupsd-3.14.8-8.fc15
Comment 37 Fedora Update System 2011-06-21 13:10:00 EDT
Package apcupsd-3.14.8-8.fc15:
* should fix your issue,
* was pushed to the Fedora 15 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing apcupsd-3.14.8-8.fc15'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/apcupsd-3.14.8-8.fc15
then log in and leave karma (feedback).
Comment 38 Fedora Update System 2011-07-08 13:59:28 EDT
apcupsd-3.14.8-8.fc15 has been pushed to the Fedora 15 stable repository.  If problems still persist, please make note of it in this bug report.

Note You need to log in before you can comment on or make changes to this bug.