Bug 453704 - nut: /sbin/upsdrvctl unable to shutdown UPS due to (unmounted) shared library
nut: /sbin/upsdrvctl unable to shutdown UPS due to (unmounted) shared library
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: nut (Show other bugs)
14
All Linux
low Severity low
: ---
: ---
Assigned To: Michal Hlavinka
Fedora Extras Quality Assurance
: Reopened, Triaged
Depends On: 519716
Blocks:
  Show dependency treegraph
 
Reported: 2008-07-02 00:38 EDT by Daryl Tester
Modified: 2011-11-09 09:08 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-11-09 09:08:49 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Daryl Tester 2008-07-02 00:38:55 EDT
Description of problem:

/sbin/upsdrvctl is used as the near final step in /etc/init.d/halt to command
the UPS to shut down power to the computer.  On this system, /usr resides on its
own partition, and nut is configured to use the /sbin/bcmxcp_usb driver (which I
believe upsdrvctl invokes to do the shutdown work).  bcmxcp_usb is dynamically
linked to /usr/lib/libusb-0.1.so.4 which it now cannot access as most of the
partitions are unmounted at this point in the halt script, so the command to
shutdown the UPS fails.

A short term solution has been to copy libusb to the /lib directory, but this
now creates a maintenance issue.

Version-Release number of selected component (if applicable):
2.2.2-1.fc9

How reproducible:
Consistently

Steps to Reproduce:
1.  Configure nut to use the bcmxcp_usb driver
2.  Configure system to have a separate /usr partition
3.  Initiate a power outage.  Note that the upsdrvctl command failure is very
hard to spot, as it's the command executed just before the system is halted and
powered off, so if a sleep is added afterwards (see bug #453700) this becomes
easier to see.
  
Actual results:
UPS fails to power off computer.

Expected results:
UPS powers off computer after configured shutdown_delay seconds (default: 120).

Additional info:
Shouldn't the binaries in the /sbin directory be statically linked to avoid this
problem?
Comment 1 Tomas Smetana 2008-07-02 02:23:06 EDT
The binaries in /sbin should have their libraries in /lib.  bcmxcp_usb is linked
to libusb so I have to consult next steps with the libusb maintainer.

Thanks for reporting.
Comment 2 Tomas Smetana 2008-07-02 03:28:48 EDT
No way of moving libusb. I'll have to link to libusb statically as you suggested.
Comment 3 Michal Hlavinka 2009-03-11 04:49:05 EDT
I was looking in this problem:

not only libusb needs to be linked statically (it was easy fix), but you also need other libraries:

# ldd usbhid-ups
 libgssapi_krb5.so.2 => /usr/lib64/libgssapi_krb5.so.2 (0x000000360aa00000)
 libkrb5.so.3 => /usr/lib64/libkrb5.so.3 (0x000000360be00000)
 libk5crypto.so.3 => /usr/lib64/libk5crypto.so.3 (0x000000360b200000)
 libkrb5support.so.0 => /usr/lib64/libkrb5support.so.0 (0x0000003609a00000)

all from krb5-libs (krb5 package doesn't provide static libraries). I'm going to ask krb5 maintainer if he can: a) provide static libraries, or b) move libraries to /lib
Comment 4 Michal Hlavinka 2009-03-11 05:32:27 EDT
... or plan B: stop nfs later
Comment 5 Michal Hlavinka 2009-03-11 06:08:15 EDT
(In reply to comment #4)
> ... or plan B: stop nfs later  

taking back, this is not related to shutdown
Comment 6 Michal Hlavinka 2009-03-11 06:45:07 EDT
but there are more and more drivers with wrong dependency:

in drivers directory after 'make' (usb is linked statically):
# for f in `find . -maxdepth 1 -type f -executable `; do echo $f; ldd $f | grep /usr ; echo; done

./snmp-ups
        libsensors.so.4 => /usr/lib64/libsensors.so.4 (0x0000003603600000)
        libnetsnmp.so.15 => /usr/lib64/libnetsnmp.so.15 (0x0000003ccc600000)

./usbhid-ups
        libgssapi_krb5.so.2 => /usr/lib64/libgssapi_krb5.so.2 (0x0000003ccca00000)
        libkrb5.so.3 => /usr/lib64/libkrb5.so.3 (0x0000003ccd200000)              
        libk5crypto.so.3 => /usr/lib64/libk5crypto.so.3 (0x000000360b200000)      
        libkrb5support.so.0 => /usr/lib64/libkrb5support.so.0 (0x0000003609a00000)

./hald-addon-bcmxcp_usb
        libhal.so.1 => /usr/lib64/libhal.so.1 (0x0000003643e00000)
        libdbus-glib-1.so.2 => /usr/lib64/libdbus-glib-1.so.2 (0x0000003a6f000000)

./netxml-ups
        libneon.so.27 => /usr/lib64/libneon.so.27 (0x0000000000c82000)
        libgnutls.so.26 => /usr/lib64/libgnutls.so.26 (0x0000003a2de00000)
        libpakchois.so.0 => /usr/lib64/libpakchois.so.0 (0x0000000000739000)
        libgssapi_krb5.so.2 => /usr/lib64/libgssapi_krb5.so.2 (0x0000003ccca00000)
        libkrb5.so.3 => /usr/lib64/libkrb5.so.3 (0x0000003ccd200000)
        libk5crypto.so.3 => /usr/lib64/libk5crypto.so.3 (0x000000360b200000)
        libtasn1.so.3 => /usr/lib64/libtasn1.so.3 (0x0000003617000000)
        libkrb5support.so.0 => /usr/lib64/libkrb5support.so.0 (0x0000003609a00000)

./powerman-pdu
        libpowerman.so.0 => /usr/lib64/libpowerman.so.0 (0x00000000009bb000)

./hald-addon-usbhid-ups
        libhal.so.1 => /usr/lib64/libhal.so.1 (0x0000003643e00000)
        libdbus-glib-1.so.2 => /usr/lib64/libdbus-glib-1.so.2 (0x0000003a6f000000)
        libgssapi_krb5.so.2 => /usr/lib64/libgssapi_krb5.so.2 (0x0000003ccca00000)
        libkrb5.so.3 => /usr/lib64/libkrb5.so.3 (0x0000003ccd200000)
        libk5crypto.so.3 => /usr/lib64/libk5crypto.so.3 (0x000000360b200000)
        libkrb5support.so.0 => /usr/lib64/libkrb5support.so.0 (0x0000003609a00000)

./hald-addon-tripplite_usb
        libhal.so.1 => /usr/lib64/libhal.so.1 (0x0000003643e00000)
        libdbus-glib-1.so.2 => /usr/lib64/libdbus-glib-1.so.2 (0x0000003a6f000000)

./hald-addon-megatec_usb
        libhal.so.1 => /usr/lib64/libhal.so.1 (0x0000003643e00000)
        libdbus-glib-1.so.2 => /usr/lib64/libdbus-glib-1.so.2 (0x0000003a6f000000)


It's going to be mooore complicated
Comment 7 Bug Zapper 2009-06-09 21:52:57 EDT
This message is a reminder that Fedora 9 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 9.  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 '9'.

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 9'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 9 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 8 Michal Hlavinka 2009-06-15 06:07:10 EDT
this problem still exists in F12/rawhide
Comment 9 Bug Zapper 2009-11-16 03:08:47 EST
This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle.
Changing version to '12'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 10 Bug Zapper 2010-11-04 07:51:42 EDT
This message is a reminder that Fedora 12 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 12.  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 '12'.

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 12'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 12 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 11 Bug Zapper 2010-12-05 02:10:01 EST
Fedora 12 changed to end-of-life (EOL) status on 2010-12-02. Fedora 12 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.
Comment 12 Michal Hlavinka 2010-12-06 09:18:28 EST
this problem still exists in F14/rawhide
Comment 13 Michal Hlavinka 2011-11-09 09:08:49 EST
ldd /sbin/bcmxcp_usb | grep /usr prints nothing now

libusb is in /lib{64} now. We can't move all libraries for all drivers, but most of them should work now.

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