Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1693048 - apcupsd: error while loading shared libraries
Summary: apcupsd: error while loading shared libraries
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora EPEL
Classification: Fedora
Component: apcupsd
Version: epel7
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Jason Tibbitts
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-03-27 03:02 UTC by Carl George
Modified: 2019-03-28 01:37 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-03-27 19:30:23 UTC


Attachments (Terms of Use)

Description Carl George 2019-03-27 03:02:12 UTC
Description of problem:
Starting apcupsd.service on CentOS 7 fails.

Version-Release number of selected component (if applicable):
apcupsd-3.14.14-5.el7

How reproducible:
always

Steps to Reproduce:
1. yum install apcupsd
2. systemctl start apcupsd.service

Actual results:
/sbin/apcupsd: error while loading shared libraries: libusb-1.0.so.0: cannot open shared object file: No such file or directory

Expected results:
successful startup

Additional info:
apcupsd requires libusb-0.1.so.4 from libusb, but the error message mentions libusb-1.0.so.0, which is provided by libusbx.  Strangely enough, /sbin/apcupsd links against both, but RPM only added the dependency for the first.

    # ldd /sbin/apcupsd | grep libusb
    	libusb-0.1.so.4 => /lib64/libusb-0.1.so.4 (0x00007f260823e000)
    	libusb-1.0.so.0 => /lib64/libusb-1.0.so.0 (0x00007f260721f000)
    # rpm -q --requires apcupsd | grep libusb
    libusb-0.1.so.4()(64bit)

Manually installing libusbx allowed apcupsd to start.

Comment 1 Jason Tibbitts 2019-03-27 16:22:02 UTC
My hope is that something changed in RHEL since the last time this was built and it just needs a rebuild.  There's a zero-change scratch build at https://koji.fedoraproject.org/koji/taskinfo?taskID=33795361.  I didn't even change the release so you will need to force the update.  If that works for you then I'll queue a proper rebuild.

I have no way to test on EL7 and only kept the branch live when I took over the package because it built there without changes.  If it's truly broken there and nobody provides a fix then I guess I'll just drop the package from EPEL.

Comment 2 Carl George 2019-03-27 19:30:23 UTC
The rebuild is the same, it only requires libusb-0.1.so.4, but has a binary that links to both libusb-0.1.so.4 and libusb-1.0.so.0.  However, installing this scratch apcupsd pulled in libusbx in the transaction this time.  I tried again in a CentOS 7 container with the apcupsd from EPEL and it too pulls in libusbx.  Upon closer inspection, libusb requires libusbx!  I don't know why my machine at home failed to install libusbx when I installed apcupsd, but at this point I think it's a problem isolated to my machine and not something that needs to be fixed in apcupsd.  Sorry for the trouble and not verifying this thoroughly enough on my end.

It seems libusb is a compatibility layer for apps that haven't ported to libusb-1.0 ABI [0].  There is a note in the apcupsd manual that says "apcupsd does not support the new 1.0 APIs" (albeit in the Mac section) [1].  Rebuilding apcupsd with only libusbx-devel fails.  Rebuilding it with both libusb-devel and libusbx-devel worked but still didn't result in the package depending on libusb-1.0.so.0.  I still think something is funky with an rpm file having a binary that links to libusb-1.0.so.0 but not getting the dependency automatically added, but I have no idea how to fix it.

[0]: https://git.centos.org/blob/rpms!libusb.git/c7/SPECS!libusb.spec#L16
[1]: http://www.apcupsd.org/manual/manual.html

Comment 3 Carl George 2019-03-28 01:37:19 UTC
I found the problem.  On that machine I had plexmediaserver-1.13.9.5456-ecd600442 installed, which was not properly filtering its bundled libraries, and was thus incorrectly providing libusb-1.0.so.0.  This caused the installation of libusb to not pull in libusbx as a dependency.  The latest version of the plexmediaserver rpm has fixed the problem, so I just needed to update it.

Sorry again to bother you with a bogus bug, I was so sure of what I was seeing that I didn't verify it in a clean environment.  Dang vendor RPMs.  :)


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