shutdown machine apcupsd --killpower dont work

Bug #134484 reported by ml
2
Affects Status Importance Assigned to Milestone
apcupsd (Debian)
Fix Released
Unknown
apcupsd (Ubuntu)
Fix Released
Undecided
Unassigned

Bug Description

Hi I'have ubuntu 7.04 server with apcupsd 3.12.4-2
with apcupsd -k and apctest and then killpower I can shutdown the ups without problems
but if disconnect the ups energy cable from the wall (and then machine start make the shutdown) but the ups remain up (aka apcupsd --killpower dont work).

Revision history for this message
In , Samuele Giovanni Tonon (samu) wrote : Bug#316932: fixed in apcupsd 3.10.18-1

Source: apcupsd
Source-Version: 3.10.18-1

We believe that the bug you reported is fixed in the latest version of
apcupsd, which is due to be installed in the Debian FTP archive:

apcupsd-cgi_3.10.18-1_i386.deb
  to pool/main/a/apcupsd/apcupsd-cgi_3.10.18-1_i386.deb
apcupsd-doc_3.10.18-1_all.deb
  to pool/main/a/apcupsd/apcupsd-doc_3.10.18-1_all.deb
apcupsd_3.10.18-1.diff.gz
  to pool/main/a/apcupsd/apcupsd_3.10.18-1.diff.gz
apcupsd_3.10.18-1.dsc
  to pool/main/a/apcupsd/apcupsd_3.10.18-1.dsc
apcupsd_3.10.18-1_i386.deb
  to pool/main/a/apcupsd/apcupsd_3.10.18-1_i386.deb
apcupsd_3.10.18.orig.tar.gz
  to pool/main/a/apcupsd/apcupsd_3.10.18.orig.tar.gz

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to <email address hidden>,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Samuele Giovanni Tonon <email address hidden> (supplier of updated apcupsd package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing <email address hidden>)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.7
Date: Thu, 11 Aug 2005 11:40:35 +0200
Source: apcupsd
Binary: apcupsd-doc apcupsd-cgi apcupsd
Architecture: source i386 all
Version: 3.10.18-1
Distribution: unstable
Urgency: low
Maintainer: Samuele Giovanni Tonon <email address hidden>
Changed-By: Samuele Giovanni Tonon <email address hidden>
Description:
 apcupsd - APC UPS Power Management
 apcupsd-cgi - Cgi for APC UPS Power Management
 apcupsd-doc - Documentation for apcupsd
Closes: 256261 310460 313642 315928 316398 316932 321929
Changes:
 apcupsd (3.10.18-1) unstable; urgency=low
 .
   * New Upstream Release (Closes: #315928)
   * apcupsd-3.10.17 is now in stable (Closes: #256261)
   * Fixed NEWS file (Closes: #310460)
   * Provides Virtual Package ups-monitor added (Closes: #316398)
   * Better doc for NISPORT (Closes: #321929)
   * Other information on NEWS file inserted (Closes: #313642) (Closes: #316932)
Files:
 dec5ba20b57142aa954b3851fa2d2841 765 - extra apcupsd_3.10.18-1.dsc
 7e66988105314eff0a0f3da4be99402d 5673946 - extra apcupsd_3.10.18.orig.tar.gz
 513ad48a326b7cd7de4686ad99396614 50181 - extra apcupsd_3.10.18-1.diff.gz
 d6d3664e3229cb1b8aa122e151a02457 304962 admin extra apcupsd_3.10.18-1_i386.deb
 529acf53ab5c0addf6040ff9817608cf 46708 web extra apcupsd-cgi_3.10.18-1_i386.deb
 8aef5207fda378a8e361fd3cca8fbaab 3129314 doc extra apcupsd-doc_3.10.18-1_all.deb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFC+x9PzvFcH/JZfgQRAh2LAJ90RWa//ej+PR4Jr9OR0dczV0ZEHQCeKD4m
JMETqyxPc+DpfyWNymhgpLM=
=XqdS
-----END PGP SIGNATURE-----

Revision history for this message
In , Peter Mogensen (apm-mutex) wrote : apcupsd: There's still problems with killpower

Package: apcupsd
Version: 3.12.3-1
Followup-For: Bug #316932

The fix in 3.10.18-1 does not work when /usr can not simply be remounted.
Specific: When /usr is on an LVM and RAID device, LVM and RAID has already been stopped when killpower is executed.
Maybe the general solution is a staticly linked killpower binary?

-- System Information:
Debian Release: testing/unstable
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.16-2-486
Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8)

Versions of packages apcupsd depends on:
ii libc6 2.3.6.ds1-4 GNU C Library: Shared libraries
ii libncurses5 5.5-3 Shared libraries for terminal hand
ii libsnmp9 5.2.3-1 NET SNMP (Simple Network Managemen
ii libssl0.9.8 0.9.8c-1 SSL shared libraries
ii libwrap0 7.6.dbs-11 Wietse Venema's TCP wrappers libra

apcupsd recommends no packages.

-- no debconf information

Revision history for this message
In , Samuele Giovanni Tonon (samu-linuxasylum) wrote : Re: Bug#316932: apcupsd: There's still problems with killpower

Peter Mogensen wrote:
> Package: apcupsd
> Version: 3.12.3-1
> Followup-For: Bug #316932
>
>
> The fix in 3.10.18-1 does not work when /usr can not simply be remounted.
> Specific: When /usr is on an LVM and RAID device, LVM and RAID has already been stopped when killpower is executed.
> Maybe the general solution is a staticly linked killpower binary?

i'm thinking of putting killpower in /bin directory and advise
the authors to move the binary to that place.

cheers
Samuele

--
4% fats, 2% cerebral activities

Revision history for this message
In , William Ono (debian-events) wrote :

> Peter Mogensen wrote:
> > The fix in 3.10.18-1 does not work when /usr can not simply be remounted.
> > Specific: When /usr is on an LVM and RAID device, LVM and RAID has already been stopped when killpower is executed.
> > Maybe the general solution is a staticly linked killpower binary?

On Fri, Sep 29, 2006 at 09:27:23AM +0200, Samuele Giovanni Tonon wrote:
> i'm thinking of putting killpower in /bin directory and advise
> the authors to move the binary to that place.

Ping...

Any chance a solution to this will arrive soon? apcupsd is half useless
on systems affected by this, such as mine.

Let me/us know if you need help.

Thanks.

--
William Ono <email address hidden>

Revision history for this message
In , Samuele Giovanni Tonon (samu-linuxasylum) wrote :

William Ono wrote:
>> Peter Mogensen wrote:
>>> The fix in 3.10.18-1 does not work when /usr can not simply be remounted.
>>> Specific: When /usr is on an LVM and RAID device, LVM and RAID has already been stopped when killpower is executed.
>>> Maybe the general solution is a staticly linked killpower binary?
>
> On Fri, Sep 29, 2006 at 09:27:23AM +0200, Samuele Giovanni Tonon wrote:
>> i'm thinking of putting killpower in /bin directory and advise
>> the authors to move the binary to that place.
>
> Ping...
>
> Any chance a solution to this will arrive soon? apcupsd is half useless
> on systems affected by this, such as mine.
>
> Let me/us know if you need help.
>
> Thanks.

Hello,
Lately i have been quite busy so i wrote something in my todo list but
didn't do anything :-(

For what i remember problem is related to the fact that apcupsd depends
on some library in /usr/lib (libnetsnmp and libcrypto if i remember
correctly) so i can see 2 solutions:

move libsnmp to /lib (so ask libsnmp maintainer to move it)
create an apcupsd withour snmp support and this will be used only on
server with LVM RAID device but not SNMP (both can't work together).

i will work on that the next days, what solution would you think is best ?

Regards
Samuele

--
While various networks have become deeply rooted, and thoughts have been
sent out as light and electrons in a singular direction, this era has
yet to digitize/computerize to the degree necessary for individuals to
become a singular complex entity.
   KOUKAKU KIDOUTAI Stand Alone Complex

Revision history for this message
In , William Ono (debian-events) wrote :

On Sat, Dec 30, 2006 at 11:25:34AM +0100, Samuele Giovanni Tonon wrote:
> Lately i have been quite busy so i wrote something in my todo list but
> didn't do anything :-(

It's indeed a busy time of year! Thanks for checking into this.

> For what i remember problem is related to the fact that apcupsd depends
> on some library in /usr/lib (libnetsnmp and libcrypto if i remember
> correctly)

Yes, and it seems libz as well:

wmono@flip:~$ dpkg -l apcupsd | grep apcupsd
ii apcupsd 3.12.4-2 APC UPS Power Management
wmono@flip:~$ ldd /sbin/apcupsd | grep usr
        libcrypto.so.0.9.8 => /usr/lib/libcrypto.so.0.9.8 (0x00002b24eca89000)
  libnetsnmp.so.9 => /usr/lib/libnetsnmp.so.9 (0x00002b24eccfd000)
  libz.so.1 => /usr/lib/libz.so.1 (0x00002b24ed311000)

> so i can see 2 solutions:
> move libsnmp to /lib (so ask libsnmp maintainer to move it)
> create an apcupsd withour snmp support and this will be used only on
> server with LVM RAID device but not SNMP (both can't work together).

Or: compile apcupsd statically linked against those 'troublesome'
libraries. I think this was suggested previously. While it would
require keeping on top of any security updates for those libraries, and
bloat the binary, it would make really sure they're always available.

Remounting /usr is a clever hack but one that seems a bit outside the
scope of this package to do. It would be nice for this step to go away
for all systems, not just ones mounting /usr from LVM/RAID.

Cheers.

--
William Ono <email address hidden>

Revision history for this message
ml (ml-ambientesc) wrote :

Hi I'have ubuntu 7.04 server with apcupsd 3.12.4-2
with apcupsd -k and apctest and then killpower I can shutdown the ups without problems
but if disconnect the ups energy cable from the wall (and then machine start make the shutdown) but the ups remain up (aka apcupsd --killpower dont work).

Changed in apcupsd:
status: Unknown → Fix Released
Revision history for this message
In , Alfred G. de Wijn (dwijn) wrote : apcupsd: problem still exists in 3.14.2-1

Package: apcupsd
Version: 3.14.2-1
Followup-For: Bug #316932

apcupsd still fails to power down the UPS, but does shut down the system
if /usr cannot be remounted. My /usr is on an LVM device.

Is there any hope for a fix in the near future?

Thanks,
Alfred

-- System Information:
Debian Release: lenny/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.23-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages apcupsd depends on:
ii libc6 2.7-4 GNU C Library: Shared libraries
ii libncurses5 5.6+20071124-1 Shared libraries for terminal hand
ii libsnmp15 5.4.1~dfsg-4 SNMP (Simple Network Management Pr
ii libssl0.9.8 0.9.8g-3 SSL shared libraries
ii libwrap0 7.6.dbs-14 Wietse Venema's TCP wrappers libra

Versions of packages apcupsd recommends:
ii apcupsd-doc 3.14.2-1 APC UPS Power Management (document

-- no debconf information

Revision history for this message
In , Joel Franco (joel-franco) wrote : Re: Bug#316932: apcupsd: problem still exists in 3.14.2-1

My ugly quick fix:

In the /etc/apcupsd/killpower enable the commented lines:

- For machines with software RAID:
    /etc/init.d/mdadm start
    /etc/init.d/mdadm-raid start

- For machines with LVM (if have raid too, use the 2 lines from RAID too):
    /etc/init.d/lvm2 start

- After this, mount the usr partition:

    mount -n -o ro /usr

Hope this terrible things help

--
Joel Franco Guzmán

On Thu Dec 13 07 23:51, Alfred G. de Wijn wrote:
> Package: apcupsd
> Version: 3.14.2-1
> Followup-For: Bug #316932
>
> apcupsd still fails to power down the UPS, but does shut down the system
> if /usr cannot be remounted. My /usr is on an LVM device.
>
> Is there any hope for a fix in the near future?
>
> Thanks,
> Alfred
>
> -- System Information:
> Debian Release: lenny/sid
> APT prefers unstable
> APT policy: (500, 'unstable')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 2.6.23-1-amd64 (SMP w/2 CPU cores)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/bash
>
> Versions of packages apcupsd depends on:
> ii libc6 2.7-4 GNU C Library: Shared libraries
> ii libncurses5 5.6+20071124-1 Shared libraries for terminal hand
> ii libsnmp15 5.4.1~dfsg-4 SNMP (Simple Network Management Pr
> ii libssl0.9.8 0.9.8g-3 SSL shared libraries
> ii libwrap0 7.6.dbs-14 Wietse Venema's TCP wrappers libra
>
> Versions of packages apcupsd recommends:
> ii apcupsd-doc 3.14.2-1 APC UPS Power Management (document
>
> -- no debconf information
>
>
>
> --
> To unsubscribe, send mail to <email address hidden>.

Revision history for this message
In , Brad King (brad.king) wrote :

Hi Folks,

I have a debian 'testing' system with /usr under lvm2 control and hit
this problem. I've gotten killpower working with a slightly patched
apcupsd 3.14.3-2, as follows:

   $ apt-get source apcupsd
   $ sudo apt-get build-dep apcupsd
   $ cd apcupsd-3.14.3
   $ patch -p1 < ~/apcupsd-lvm.patch
   $ fakeroot debian/rules binary

Then install the .deb files produced for apcupsd and apcupsd-doc and
configure as normal. The patch switches to linking against static
libnetsnmp, libcrypto, and libz. It also removes a call to 'wall' during
apccontrol killpower (for some reason the echo before apcupsd --killpower
does not use wall but the call after it does, so I removed the extra call).

apcupsd-lvm.patch
------------------------------------------------------------------------------
diff --git a/configure b/configure
index 9983225..d49fedd 100755
--- a/configure
+++ b/configure
@@ -11972,7 +11972,7 @@ fi
  echo "$as_me:$LINENO: result: $ac_cv_lib_crypto_EVP_DigestInit" >&5
  echo "${ECHO_T}$ac_cv_lib_crypto_EVP_DigestInit" >&6
  if test $ac_cv_lib_crypto_EVP_DigestInit = yes; then
- echo ' including crypto library for snmp.'; DRVLIBS="$DRVLIBS -lcrypto"
+ echo ' including crypto library for snmp.'; DRVLIBS="$DRVLIBS -Wl,-Bstatic -lcrypto -lz -Wl,-Bdynamic"
  fi

@@ -12048,7 +12048,7 @@ fi
  echo "$as_me:$LINENO: result: $ac_cv_lib_netsnmp_snmp_open" >&5
  echo "${ECHO_T}$ac_cv_lib_netsnmp_snmp_open" >&6
  if test $ac_cv_lib_netsnmp_snmp_open = yes; then
- DRVLIBS="$DRVLIBS -lnetsnmp"
+ DRVLIBS="-Wl,-Bstatic -lnetsnmp -Wl,-Bdynamic $DRVLIBS"
            SNMP_LIB_FOUND="yes"
  fi

diff --git a/platforms/apccontrol.in b/platforms/apccontrol.in
index cc2aae9..e8fa840 100644
--- a/platforms/apccontrol.in
+++ b/platforms/apccontrol.in
@@ -61,7 +61,7 @@ case "$1" in
   echo "Apccontrol doing: ${APCUPSD} --killpower on UPS ${2}"
   sleep 10
   ${APCUPSD} --killpower
- echo "Apccontrol has done: ${APCUPSD} --killpower on UPS ${2}" | ${WALL}
+ echo "Apccontrol has done: ${APCUPSD} --killpower on UPS ${2}"
      ;;
      commfailure)
   echo "Warning communications lost with UPS ${2}" | ${WALL}
------------------------------------------------------------------------------

I hope this solution helps others.

-Brad

Daniel T Chen (crimsun)
Changed in apcupsd:
status: New → Fix Released
Revision history for this message
In , Adam Kropelin (adk0212) wrote : New apcupsd snmplite driver eliminates need for net-snmp library

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.

Revision history for this message
In , Elliott Mitchell (ehem) wrote : Static Linking Isn't Good

Given libsnmp's suboptimal security history, might I suggest statically
linking with it is a /bad/ idea? Wouldn't it be better to create a
separate /sbin/apc-killpower command that takes care of shutting the
UPS down?

How does this bug manage to rate "important" severity, not "grave"
severity?

--
(\___(\___(\______ --=> 8-) EHM <=-- ______/)___/)___/)
 \BS ( | <email address hidden> PGP F6B23DE0 | ) /
  \_CS\ | _____ -O #include <stddisclaimer.h> O- _____ | / _/
2477\___\_|_/DC21 03A0 5D61 985B <-PGP-> F2BE 6526 ABD2 F6B2\_|_/___/3DE0

Changed in apcupsd (Debian):
status: Fix Released → New
Changed in apcupsd (Debian):
status: New → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.