Bug 453704

Summary: nut: /sbin/upsdrvctl unable to shutdown UPS due to (unmounted) shared library
Product: [Fedora] Fedora Reporter: Daryl Tester <dt-fedbugz>
Component: nutAssignee: Michal Hlavinka <mhlavink>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: low Docs Contact:
Priority: low    
Version: 14CC: jnovy
Target Milestone: ---Keywords: Reopened, Triaged
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-11-09 14:08:49 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 519716    
Bug Blocks:    

Description Daryl Tester 2008-07-02 04:38:55 UTC
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 06:23:06 UTC
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 07:28:48 UTC
No way of moving libusb. I'll have to link to libusb statically as you suggested.

Comment 3 Michal Hlavinka 2009-03-11 08:49:05 UTC
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 09:32:27 UTC
... or plan B: stop nfs later

Comment 5 Michal Hlavinka 2009-03-11 10:08:15 UTC
(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 10:45:07 UTC
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-10 01:52:57 UTC
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 10:07:10 UTC
this problem still exists in F12/rawhide

Comment 9 Bug Zapper 2009-11-16 08:08:47 UTC
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 11:51:42 UTC
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 07:10:01 UTC
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 14:18:28 UTC
this problem still exists in F14/rawhide

Comment 13 Michal Hlavinka 2011-11-09 14:08:49 UTC
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.