similar to: Data Stale at random intervals

Have done more Googling and searching around the system. Found that /lib/udev/rules.d/52-nut-usbups.rules has been changed to 62 by others and also in Sid (2.7.4) so gave that a shot. Will post back with results. ________________________________ From: Daniel Shields <grungelizard9 at hotmail.com> Sent: Monday, October 10, 2016 10:51 PM To: nut-upsuser at lists. alioth. debian. org

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

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 <grungelizard9 at

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

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:

Also, I have replaced the cable and have tried to install on Raspbian with the same issue. Seems I may be missing something in the configuration, but haven't been able to find anything yet. On October 10, 2016, at 9:39 PM, Daniel Shields <grungelizard9 at hotmail.com> wrote: Hello All, Been at this for a few weeks, so figured I'd reach out. I was previously running

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

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

No joy. Reverted. ________________________________ From: Daniel Shields <grungelizard9 at hotmail.com> Sent: Tuesday, October 11, 2016 9:19 PM To: nut-upsuser at lists. alioth. debian. org Cc: Daniel Shields Subject: Re: Data Stale at random intervals Have done more Googling and searching around the system. Found that /lib/udev/rules.d/52-nut-usbups.rules has been changed to 62 by

Hello, I have a Raspberry Pi model B running Raspbian Stretch. I have installed version 2.7.4-5 of nut from the raspbian repos. I have a CyberPower 1500PFCLCD UPS. When I reboot the Pi, the nut-server service fails to start. root at nut:~# service nut-server status ? nut-server.service - Network UPS Tools - power devices information server Loaded: loaded

- Charles > 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

Hi Charles, Tried it with -p but couldn't get it to run, I'll have to dig further into the man pages. I ran without -p though and got an interesting timeout error. Attached is the log. I'll look further into the -p option as well. Tried sending the full zipped log but it was too big. Attaching the part where the error occurred. It seems like it was able to recover a couple

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

Hello all. I have installed Nut on a Raspberry PI and all looks to be configured correctly, but I get stale data and communications lost at random intervals. I tried running nut-driver in gcc to see if I could find any clues there, but it ran for about 24 hours with no sign of an issue. However, when I let Nut run normally, it seems to be anywhere from 2 to 8 hours and the data goes stale and

On Oct 22, 2017, at 2:39 AM, Daniel Shields <grungelizard9 at hotmail.com> wrote: > > Oct 22 05:57:37 nut.tklapp.com upsd[341]: not listening on 192.168.213.189 port 3493 > Oct 22 05:57:37 nut.tklapp.com upsd[341]: not listening on 192.168.213.189 port 3493 > Oct 22 05:57:37 nut.tklapp.com upsd[341]: listening on 127.0.0.1 port 3493 > Oct 22 05:57:37 nut.tklapp.com upsd[341]:

Hi Charles, I've been monitoring for the past few days and NUT has been running solid. Tested and everything's working as it should. Thanks for all of your help on this, great to have it running well again and learned lot. ________________________________ From: Daniel Shields <grungelizard9 at hotmail.com> Sent: Tuesday, October 25, 2016 8:01 PM To: Charles Lepple Subject:

On Oct 12, 2016, at 8:13 PM, Daniel Shields <grungelizard9 at hotmail.com> wrote: > > Wow. Okay, well I let the debug run all day. Nothing in the logs even with debug cranked to level 5. Attached are the last 1000 lines before it quit. I'm really stumped now. gzipped and resent for the rest of the list. Can you elaborate on how it quit? I don't see any error messages to

So, let's get started! One of the first changes we might want to do is move away /etc/sysconfig/xendomains... We should put it either in /etc/default/xendomains (since it's an init script configuration) or /etc/xen/xendomains (since it's xen related)... Which one do you prefer? As for the way to do it I propose a dpatch file that changes the two files in the upstream tarball that

Hi Charles, Ok, I missed the absence from the backports as well. Again, some unfamiliarity here, so 1) I presume I cannot use a metapackage meant for jessie or stretch on wheezy? Or if I can, is there a way to deploy it from console? 2) If not and I use the 2.7.4 tar found at http://networkupstools.org/download.html, do i just run the classical process? i.e. ./configure make sudo make install

Hi, I''ve defined this module: package {[''build-essential'', "linux-headers-${kernelrelease}", ''dkms'', ''linux-headers-server'']: ensure => installed, } and when the package linux-headers-server it''s upgraded in the repositories puppet tries to upgrade in client too. And as that package has a dependency