# ldd /lib64/nut/usbhid-ups linux-vdso.so.1 (0x00007ffdfe3e3000) libusb-0.1.so.4 => /lib64/libusb-0.1.so.4 (0x00007f98526e6000) <-- from libusbp-compat-0.1.5-r2 libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f98524ca000) libc.so.6 => /lib64/libc.so.6 (0x00007f985212f000) libusb-1.0.so.0 => /lib64/libusb-1.0.so.0 (0x00007f9851f17000) <-- from libusb-1.0.19 /lib64/ld-linux-x86-64.so.2 (0x00007f98528ec000) libudev.so.1 => /lib64/libudev.so.1 (0x00007f9852aa6000) librt.so.1 => /lib64/librt.so.1 (0x00007f9851d0f000) libm.so.6 => /lib64/libm.so.6 (0x00007f9851a14000) libresolv.so.2 => /lib64/libresolv.so.2 (0x00007f98517fd000) libcap.so.2 => /lib64/libcap.so.2 (0x00007f98515f7000) libattr.so.1 => /lib64/libattr.so.1 (0x00007f98513f2000)
I haven't cracked open the nut sources yet, but am curious why it should fail to open the usb device after already succeeding many times. Could it be a USB power management issue? Or simply opening it too many times somehow breaks it? On Thu, Dec 31, 2015 at 4:06 PM, Charles Lepple <clep...@gmail.com> wrote: > On Dec 31, 2015, at 5:31 PM, Nicholas Leippe <lei...@gmail.com> wrote: > > > > Is this something to cross post to linux-usb? > > I guess, although they might need to know some additional details about > your libusb configuration (real libusb-0.1.x, or libusb-1.x with > libusb-compat). > > Here is the relevant portion of the code: > > https://github.com/networkupstools/nut/blob/master/drivers/libusb.c#L262 > > > On Mon, Nov 23, 2015 at 8:47 PM, Charles Lepple <clep...@gmail.com> > wrote: > > On Nov 20, 2015, at 11:22 AM, Nicholas Leippe <lei...@gmail.com> wrote: > > > > > > 1389.279158 Trying to match device > > > 1389.279164 Device matches > > > 1389.279169 failed to claim USB device: Device or resource busy > > > 1389.279175 failed to detach kernel driver from USB device: No > such file or directory > > > > Can you check around and see if anyone else has any wisdom on this error > message? I vaguely recall trying to track this down, and not finding the > ENOENT error in the kernel code. > > > > > upsdrvctl is not noticing this exit, so the openrc service scripts get > into a stuck state also--I have to stop, then zap the upsdrv service before > I can start it again. > > > Each time it works fine for some non-deterministic amount of time then > dies. > > > > So the usbhid-ups driver is no longer running at that point? upsdrvctl > just starts the driver(s) - it does not stick around, at least not in the > default NUT configuration. I am not familiar with openrc, but in general, > making the init system track one or more driver PIDs in a generic fashion > is an unsolved problem. > > > > That said, I'm wondering if NUT is retrying too quickly. (The default > retry works fine for an older MGE on a slightly-less-old Soekris box > running BSD - it reconnects about once every day or two. But I don't have > any Gentoo boxes or 4.x kernels to test against at the moment.) > > > > -- > > 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