search for: nailbunny

Here are the results of a restart as well as a stop/start. Seems like it may be the server? I tried to run the nut-server service with gdb, but no luck getting it to work so far. Thanks! ________________________________ From: Charles Lepple <clepple at gmail.com> Sent: Wednesday, October 12, 2016 8:20 PM To: Daniel Shields Cc: nut-upsuser at lists. alioth. debian. org Subject: Re:

Just an update, these messages are in the syslog when nut is no longer able to communicate with the server: Oct 14 01:41:59 golgotha upsmon[1300]: Poll UPS [nailbunny at localhost] failed - Data stale Oct 14 01:42:04 golgotha upsmon[1300]: Poll UPS [nailbunny at localhost] failed - Data stale Oct 14 01:42:09 golgotha upsmon[1300]: Poll UPS [nailbunny at localhost] failed - Data stale Oct 14 01:42:14 golgotha upsmon[1300]: Poll UPS [nailbunny at localhost] failed...

Ran with gdb: gdb /lib/nut/usbhid-ups run -u nut -a nailbunny -x bus=010 -x vendorid=0764 -x productid=0501 -DDDDD Same result as when I ran normally. Driver just stops communicating with no errors or messages in the logs. Not sure where to go from here as I'm not seeing anything to follow up on. ________________________________ From: Daniel Shields...

Hi Charles, Thanks for the tip. I reran the debug again until communication stopped. Backtrace is below. Thanks! 441.204990 upsdrv_updateinfo... (Driver stopped communicating) Broadcast message from nut at golgotha.tklapp.com (somewhere) (Sat Oct 15 03:36:57 UPS nailbunny at localhost is unavailable ^C Program received signal SIGINT, Interrupt. 0x00007ffff76ec1c7 in ioctl () from /lib/x86_64-linux-gnu/libc.so.6 (gdb) bt #0 0x00007ffff76ec1c7 in ioctl () from /lib/x86_64-linux-gnu/libc.so.6 #1 0x00007ffff7bd69e5 in ?? () from /lib/x86_64-linux-gnu/libusb-0.1.so.4...

...y appreciated. Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20161011/c04b3940/attachment-0001.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: Nailbunny Debug.7z Type: application/octet-stream Size: 5855 bytes Desc: Nailbunny Debug.7z URL: <http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20161011/c04b3940/attachment-0002.obj> -------------- next part -------------- A non-text attachment was scrubbed... Name: Nailbunny Syslog....

I've been testing with debug further and there's a few extra lines when the nut-server stops communicating as opposed to when it's running. Backtrace after stale data, UPS nailbunny at localhost is unavailable: ^C Program received signal SIGINT, Interrupt. 0x00007ffff76ec1c7 in ioctl () from /lib/x86_64-linux-gnu/libc.so.6 (gdb) bt #0 0x00007ffff76ec1c7 in ioctl () from /lib/x86_64-linux-gnu/libc.so.6 #1 0x00007ffff7bd69e5 in ?? () from /lib/x86_64-linux-gnu/libusb-0.1.so....

On Oct 14, 2016, at 8:53 PM, Daniel Shields <grungelizard9 at hotmail.com> wrote: > > Ran with gdb: > > gdb /lib/nut/usbhid-ups > > run -u nut -a nailbunny -x bus=010 -x vendorid=0764 -x productid=0501 -DDDDD > > Same result as when I ran normally. Driver just stops communicating with no errors or messages in the logs. Not sure where to go from here as I'm not seeing anything to follow up on. I still haven't had a chance to look at a...

...3:34 AM, Daniel Shields <grungelizard9 at hotmail.com<mailto:grungelizard9 at hotmail.com>> wrote: I've been testing with debug further and there's a few extra lines when the nut-server stops communicating as opposed to when it's running. Backtrace after stale data, UPS nailbunny at localhost is unavailable: Sorry to take a while to get back to you on this. I wonder if it is getting stuck once at that point, or if it is repeatedly calling the same libusb function. If it is the former, then I suspect we are not going to get much help from Debian on this: https://bugs.debi...

...On Oct 16, 2016, at 3:34 AM, Daniel Shields <grungelizard9 at hotmail.com> wrote: > > I've been testing with debug further and there's a few extra lines when the nut-server stops communicating as opposed to when it's running. > > > Backtrace after stale data, UPS nailbunny at localhost is unavailable: > Sorry to take a while to get back to you on this. I wonder if it is getting stuck once at that point, or if it is repeatedly calling the same libusb function. If it is the former, then I suspect we are not going to get much help from Debian on this: https://bug...

On Oct 11, 2016, at 10:07 PM, Daniel Shields wrote: > > No joy. Reverted. A wrong number for the udev rules file would prevent the driver from starting at all due to permissions errors. It is possible that 52 and 62 are currently in the acceptable range. > > From: Daniel Shields <grungelizard9 at hotmail.com> > Sent: Tuesday, October 11, 2016 9:19 PM > To: nut-upsuser