[Nut-upsuser] usbhid-ups dying, consistently
Nicholas Leippe
leippe at gmail.com
Thu Dec 31 23:23:34 UTC 2015
# 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 <clepple at gmail.com> wrote:
> On Dec 31, 2015, at 5:31 PM, Nicholas Leippe <leippe at 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 <clepple at gmail.com>
> wrote:
> > On Nov 20, 2015, at 11:22 AM, Nicholas Leippe <leippe at 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 at gmail
> >
> >
> >
> >
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20151231/c6cd0797/attachment.html>
More information about the Nut-upsuser
mailing list