Bug#316932: apcupsd: There's still problems with killpower
Peter Mogensen
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
--
To UNSUBSCRIBE, email to debian-bugs-...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Samuele Giovanni Tonon
> 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
William Ono
> > 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 <deb...@events.soundwave.net>
Samuele Giovanni Tonon
>> 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
William Ono
> 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 <deb...@events.soundwave.net>