Bug 346271

Created attachment 234771 [details]
A patch for /etc/rc.d/init.d/halt

Here's one way to fix it.

Can you add a patch in 'diff -u' format?

Created attachment 235301 [details]
Patch in diff -u format

Oops, sorry.  Here's a diff -u patch.

The patch won't work if /usr is a separate filesystem, which will be unmounted 
at this point.

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.

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

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.

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

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

(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.

I've built new version for rawhide that has the binaries in /sbin

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.

That would need to be fixed in apcupsd.

I have opened bug 474473 (lm_sensors) and bug 474474 (net-snmp) to address the library issues.

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).

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)

Created attachment 341252 [details]
Patch for halt

This is the patch I use for halt and it works well for me.

Created attachment 341253 [details]
Patch for halt

This is the patch I use for halt and it works well for me.

Still a problem in initscripts-8.95-1.x86_64 with Fedora 11.

I feel this should have a severity other than 'low' since it essentially prevents apcupsd from functioning as designed.

I've asked fesco for exception in static linking:

https://fedorahosted.org/fesco/ticket/235

"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.

(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

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.

(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

(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

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.

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

Someone please update the version for this bug to 11 so it doesn't get tossed.

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

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

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.

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.

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)

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

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

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).

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.