So far, the systemd service unit is working perfectly. Halleluia!
For reference, here are the libs associated with the usbhid-ups driver:
rtd@linux-fnda:/etc/init.d> ldd /usr/local/ups/bin/usbhid-ups
linux-vdso.so.1 (0x00007fffecd25000)
libusb-0.1.so.4 => /usr/lib64/libusb-0.1.so.4 (0x00007ff3b841b000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007ff3b81fd000)
libc.so.6 => /lib64/libc.so.6 (0x00007ff3b7e4e000)
libusb-1.0.so.0 => /usr/lib64/libusb-1.0.so.0 (0x00007ff3b7c3e000)
/lib64/ld-linux-x86-64.so.2 (0x00007ff3b8621000)
librt.so.1 => /lib64/librt.so.1 (0x00007ff3b7a36000)
Rob Groner
Software Engineer Level II
RTD Embedded Technologies, Inc.
ISO 9001 and AS9100 Certified
Ph: +1 814-234-8087
www.rtd.com
-----Original Message-----
From: Charles Lepple [mailto:clep...@gmail.com]
Sent: Thursday, September 17, 2015 9:13 AM
To: Rob Groner <rgro...@rtd.com>
Cc: Roger Price <ro...@rogerprice.org>; nut-upsuser Mailing List
<nut-upsuser@lists.alioth.debian.org>
Subject: Re: [Nut-upsuser] UPS/NUT with openSUSE 13.1
On Sep 15, 2015, at 9:31 PM, Charles Lepple <clep...@gmail.com> wrote:
>
>> Trying to track down the source of the problem, I checked Yast to make sure
>> I had at least 0.1.8 version for libusb. I saw this (attached photo). Is
>> it then actually using –compat instead of the “real” libusb? And is that a
>> problem?
>
> You're right, both the -compat and real libusb packages will use the same
> libusb-0.1.so* name.
I misspoke.
The "real libusb" (0.1) and libusb-compat will both get linked with "-lusb".
The package management system is free to implement that with symlinks to the
actual files.
The confusing part is that openSUSE seems to be adopting the 0.1.1x numbering
scheme for libusb-compat so that the package looks newer (0.1.13) than the real
libusb-0.1.12:
https://build.opensuse.org/package/view_file/openSUSE:13.2/libusb-compat/libusb-compat.spec?expand=1
Note the changes mentioned in the return codes for
usb_detach_kernel_driver_np():
https://build.opensuse.org/package/view_file/openSUSE:13.2/libusb-compat/libusb-compat.changes?expand=1
Those are the sort of edge cases that haven't been fully tested with NUT. It
seems like the path from NUT driver through libusb to the kernel is relatively
unchanged with libusb-compat, but that mapping the errors back to root cause
will depend on the exact version of libusb-compat in use (and potentially, the
kernel version as well).
I would recommend retesting with an explicit "killall usbhid-ups" (and anything
else necessary to stop NUT background services, otherwise it will pop back up)
before switching debug flags on.
If that fails to turn up anything conclusive, you might try to install
libusb-0.1.12 from source in a separate directory, and explicitly point
./configure to that tree:
<remove libusb-compat-devel>
install from
http://sourceforge.net/projects/libusb/files/libusb-0.1%20%28LEGACY%29/0.1.12/
.../libusb-0.1.12 $ ./configure --prefix=$HOME/local/libusb-0.1 && make && sudo
make install
.../nut $ ./configure --with-usb-include=$HOME/local/libusb-0.1/include
--with-usb-libs=-L$HOME/local/libusb-0.1/lib ...
(might need slight adjustments)
After that, you can verify that the libusb line in "ldd /path/to/usbhid-ups"
points to "$HOME/local/..."
--
Charles Lepple
clepple@gmail
_______________________________________________
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
