similar to: nut-server service fails to start at boot

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 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]:

Hello All, Been at this for a few weeks, so figured I'd reach out. I was previously running Debian Wheezy Nut Version 2.6.4 with no issues for over 6 months on the same hardware. This issue started when I upgraded to Jessie, so just trying to get everything happy again. System is running "Linux golgotha.tklapp.com 3.16.0-4-amd64 #1 SMP Debian 3.16.36-1+deb8u1 (2016-09-03)

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

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

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

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:

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

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

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

- 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

On 12/16/2013 09:23 PM, Charles Lepple wrote: > Not sure - I didn't write the getaddrinfo() code in upsd, but it seemed to > follow all of the recommendations on how to use that function. So if there is > a way to fix it in the NUT code, I am not aware of it (and would appreciate > any updates if that turns out to be the case). > > The odd part is that it looks like you went

Hello, I have been following the details in this article to configure my UPS: http://rogerprice.org/NUT.html However the system won't shutdown although file permissions look ok: ls -alF /usr/sbin/ups* -rwxr--r-- 1 upsd daemon 64984 Oct 15 2014 /usr/sbin/upsd* -rwxr--r-- 1 upsd daemon 48584 Oct 15 2014 /usr/sbin/upsmon* -rwxr--r-- 1 upsd daemon 31536 Oct 15 2014 /usr/sbin/upssched*

I have a Dell 500w UPS and it works great with Ubuntu 12.04 LTS and Network UPS tools 2.6.3 via usb. This powers a standalone server for the purposes of clean shutdowns. This was installed using "sudo apt-get install nut" and there are no issues with the Server > nut > ups chain. I am using the usbhid-ups driver and haven't had any issues. I am trying to also add an NAS to the

Bonjour ? tous, Je n'arrive pas a faire marcher NUT avec HomeAssistant. Cela fait des mois que je suis la-dessus, mais sans succ?s ! Je ne vois plus quoi faire ! Help ! * Ubuntu 23.10 * NUT version = 2.7.4-14ubuntu2 * NUT installation method: Package * exact device name and related information : Riello IDG800 Voici les commandes que je tape sur le PC connect?

On 12/17/2013 10:43 AM, David C. Rankin wrote: > Huh? Why the : in Servname? So I just hardwired it passing the port "Servname" > as "3493" (could have just used "nut" from /etc/services): Sheepishly looking for a place to hide.... Yes there was a ':' there all right. Seems I was hit by a vi error: [12:04 phoinix:/etc/ups] # grep 3493 *.conf

Hi Charles, Thanks for your response. No, I only put 192.168.1.64 as an extra option as I want to allow Slave access from another computer. Otherwise, access will normally only be from localhost. There is only one network interface on this machine. I will try it out with "LISTEN 0.0.0.0 3493" and see what happens. I must confess I usually run without a firewall as I'm only running a

O.S.: Linux LMDE 3 "Cindy" Linux Kernel: 4.9.0-12-amd64 NUT Version: 2.4.7-5 Installed from: Debian package Driver in use: usbhid-ups UPS device: Powerwalker Basic VI 1500 STL. Identifies as Cyberpower PR1500LCDRT2U UPS VendorID 0764 ProductID 0601 Product URL:

On 12/03/2016 10:08 AM, Charles Lepple wrote: >> On Dec 3, 2016, at 11:01 AM, Jack McGee <jack at greendesk.net> wrote: >> >> I did restart those services, no change. >> > $ ps auxww|grep [/]nut > root 13074 0.0 0.0 37844 2628 ? Ss 08:42 0:00 /lib/nut/upsmon > nut 13076 0.0 0.0 45632 5148 ? S 08:42 0:00 /lib/nut/upsmon

Thanks Manuel.  I’m following that guide but am now stuck when checking to make sure the nut-sever and nut-client are up and working.  I got this: proton at proton:~$ service nut-server status nut-server.service - Network UPS Tools - power devices information server      Loaded: loaded (/lib/systemd/system/nut-server.service; enabled; vendor preset: enabled)      Active: failed (Result: