2 minutes ago, cassiusdrow said:

 

My apologies.  False alarm.  I should know better than to do upgrades after 11 PM.

 

It was the change from nut version 2.8.1 to 2.8.2 along with a configuration error on my part.  I had a bad listener entry in upsd.conf.  This didn't cause any issues for 2.8.1, but 2.8.2 now forces upsd to exit with an error if any listeners fail.  Removing the bad listener entry allowed upsd to start.  They added the ALLOW_NOT_ALL_LISTENERS setting in upsd.conf to control this behavior.  See this issue: https://github.com/networkupstools/nut/issues/723

 

Thank you for the quick reply and for all the work you have been doing on this plugin.

 

No problem - glad it works for you and thanks for using NUT. 🙂 

Hey,

 

i got a Eaton Ellipse ECO 800, but ~once a day it goes on battery for a second and switch immediately back to wall power.

 

Not sure why it does it, but the notification/email everyday from the plugin is a little bit annoying.

A configurable delay in seconds would be nice 😅

 

Edit: Reason for the battery kicking in is a "faulty?" Tasmota power plug which sometimes crashes and disconnect the power for a short time, funny that my server not cared before i had the UPS

Edited April 7, 20242 yr by Darkestnoir

Been using this plugin a while. Getting this recurring pipe error in logs ever since update.

 

Apr 7 21:39:52 Seraphys usbhid-ups[3556]: nut_libusb_get_string: Pipe error

8 hours ago, Seraphys said:

Been using this plugin a while. Getting this recurring pipe error in logs ever since update.

 

Apr 7 21:39:52 Seraphys usbhid-ups[3556]: nut_libusb_get_string: Pipe error

 

In that case you can always go back to the previous backend "previous" (2.8.1 stable) in NUT Settings.

On 4/7/2024 at 10:00 PM, Darkestnoir said:

Hey,

 

i got a Eaton Ellipse ECO 800, but ~once a day it goes on battery for a second and switch immediately back to wall power.

 

Not sure why it does it, but the notification/email everyday from the plugin is a little bit annoying.

A configurable delay in seconds would be nice 😅

 

Edit: Reason for the battery kicking in is a "faulty?" Tasmota power plug which sometimes crashes and disconnect the power for a short time, funny that my server not cared before i had the UPS

I have a Ellipse Pro 1200, it does the same test. It's a quick check of the battery health. But I don't have any notification for that test.

I have an issue with the current version (NUT 2.8.2) running on my server. I've recently connected an APC BX1600MI-GR and I've been getting error messages and two unclean/unexpected shutdowns resulting in a parity check so far. At the time of the first shutdown I was running powertop --auto-tune which had enabled the USB autosuspend. I haven't run --auto-tune since rebooting and I've also enabled the USB power management override option in NUT. I was still getting the following errors and eventually the second shutdown:

Apr  7 18:53:59 Tower usbhid-ups[3860]: nut_libusb_get_report: Input/Output Error
Apr  7 18:54:01 Tower usbhid-ups[3860]: #012Reconnecting. If you saw "nut_libusb_get_interrupt: Input/Output Error" or similar message in the log above, try setting "pollonly" flag in "ups.conf" options section for this driver!

 

So after rebooting I enabled the GUI settings override option, added pollonly = "enabled" to ups.conf, and restarted NUT. Now I was getting the following error messages in the syslog:

Apr  9 02:38:08 Tower usbhid-ups[21630]: nut_libusb_get_report: Input/Output Error
Apr  9 03:43:05 Tower usbhid-ups[21630]: nut_libusb_get_report: Input/Output Error
Apr  9 04:02:17 Tower usbhid-ups[21630]: nut_libusb_get_report: Input/Output Error
Apr  9 04:02:17 Tower kernel: usb 1-11: USB disconnect, device number 7
Apr  9 04:02:17 Tower usbhid-ups[21630]: libusb1: Could not open any HID devices: insufficient permissions on everything
Apr  9 04:02:17 Tower upsd[21675]: Data for UPS [ups] is stale - check driver
Apr  9 04:02:18 Tower upsmon[21678]: Poll UPS [[email protected]] failed - Data stale
Apr  9 04:02:18 Tower upsmon[21678]: Communications with UPS [email protected] lost
Apr  9 04:02:18 Tower kernel: usb 1-11: new low-speed USB device number 8 using xhci_hcd
Apr  9 04:02:18 Tower kernel: hid-generic 0003:051D:0002.0006: hiddev96,hidraw0: USB HID v1.10 Device [American Power Conversion Back-UPS BX1600MI] on usb-0000:00:14.0-11/input0
Apr  9 04:02:19 Tower upsd[21675]: UPS [ups] data is no longer stale
Apr  9 04:02:23 Tower upsmon[21678]: Communications with UPS [email protected] established
Apr  9 04:28:17 Tower usbhid-ups[21630]: nut_libusb_get_report: Input/Output Error
Apr  9 04:54:29 Tower usbhid-ups[21630]: nut_libusb_get_report: Input/Output Error
Apr  9 04:56:41 Tower usbhid-ups[21630]: nut_libusb_get_report: Input/Output Error

I've since switched the cable to another USB port (this morning) and haven't had an error since then (just over an hour ago). I've attached the full syslog and NUT USB diagnostics if that helps. Anyone who has an idea on what's going on?

syslog.txt UPS USB diags.txt

2 hours ago, KillianMelsen said:

I have an issue with the current version (NUT 2.8.2) running on my server. I've recently connected an APC BX1600MI-GR and I've been getting error messages and two unclean/unexpected shutdowns resulting in a parity check so far. At the time of the first shutdown I was running powertop --auto-tune which had enabled the USB autosuspend. I haven't run --auto-tune since rebooting and I've also enabled the USB power management override option in NUT. I was still getting the following errors and eventually the second shutdown:

Apr  7 18:53:59 Tower usbhid-ups[3860]: nut_libusb_get_report: Input/Output Error
Apr  7 18:54:01 Tower usbhid-ups[3860]: #012Reconnecting. If you saw "nut_libusb_get_interrupt: Input/Output Error" or similar message in the log above, try setting "pollonly" flag in "ups.conf" options section for this driver!

 

So after rebooting I enabled the GUI settings override option, added pollonly = "enabled" to ups.conf, and restarted NUT. Now I was getting the following error messages in the syslog:

Apr  9 02:38:08 Tower usbhid-ups[21630]: nut_libusb_get_report: Input/Output Error
Apr  9 03:43:05 Tower usbhid-ups[21630]: nut_libusb_get_report: Input/Output Error
Apr  9 04:02:17 Tower usbhid-ups[21630]: nut_libusb_get_report: Input/Output Error
Apr  9 04:02:17 Tower kernel: usb 1-11: USB disconnect, device number 7
Apr  9 04:02:17 Tower usbhid-ups[21630]: libusb1: Could not open any HID devices: insufficient permissions on everything
Apr  9 04:02:17 Tower upsd[21675]: Data for UPS [ups] is stale - check driver
Apr  9 04:02:18 Tower upsmon[21678]: Poll UPS [[email protected]] failed - Data stale
Apr  9 04:02:18 Tower upsmon[21678]: Communications with UPS [email protected] lost
Apr  9 04:02:18 Tower kernel: usb 1-11: new low-speed USB device number 8 using xhci_hcd
Apr  9 04:02:18 Tower kernel: hid-generic 0003:051D:0002.0006: hiddev96,hidraw0: USB HID v1.10 Device [American Power Conversion Back-UPS BX1600MI] on usb-0000:00:14.0-11/input0
Apr  9 04:02:19 Tower upsd[21675]: UPS [ups] data is no longer stale
Apr  9 04:02:23 Tower upsmon[21678]: Communications with UPS [email protected] established
Apr  9 04:28:17 Tower usbhid-ups[21630]: nut_libusb_get_report: Input/Output Error
Apr  9 04:54:29 Tower usbhid-ups[21630]: nut_libusb_get_report: Input/Output Error
Apr  9 04:56:41 Tower usbhid-ups[21630]: nut_libusb_get_report: Input/Output Error

I've since switched the cable to another USB port (this morning) and haven't had an error since then (just over an hour ago). I've attached the full syslog and NUT USB diagnostics if that helps. Anyone who has an idea on what's going on?

syslog.txt 175.46 kB · 0 downloads UPS USB diags.txt 5.36 kB · 0 downloads

 

Please post the NUT Debug Package found in NUT Settings.

1 hour ago, Rysz said:

 

Please post the NUT Debug Package found in NUT Settings.

Yes, of course! Attached it.

nut-debug-20240409133951.zip

22 minutes ago, KillianMelsen said:

Yes, of course! Attached it.

nut-debug-20240409133951.zip 120.04 kB · 0 downloads

 

There is nothing in the logs regarding the previous shutdown, please make sure to enable this:

 

And then post the NUT Debug Package again next time you get a shutdown, directly on the first boot after the shutdown. The BX series is known to be bugged (we spoke on GitHub about this) but it shouldn't cause any shutdowns, at least it didn't for any of the other affected people so far. NUT should in general never cause unclean shutdowns (and parity checks) unless something on your server was taking extremely long to stop - resulting in a forced shutdown (but this would also happen without NUT if you press "Shutdown" and something gets stuck). So even if your UPS reported a false power event the shutdown should always have been a clean shutdown. In any case we would need the logs from before the shutdown to really diagnose the problem that led to the unclean shutdown so this is guesswork on my part at best.

 

Regarding the other problems now having stopped on another USB port, I'm guessing the USB port you were previously connecting your UPS to is maybe faulty or the USB cable between the PC and the UPS is in the process of dying. There's a lot of USB related events in the logs, so I'd monitor the situation and if it happens again on the new USB port I'd consider exchanging the cable (can be found on Amazon for around 10$). Sorry I can't really help more at this point, but do report back with new logs in case it happens again.

 

Edited April 9, 20242 yr by Rysz

9 minutes ago, Rysz said:

 

There is nothing in the logs regarding the previous shutdown, please make sure to enable this:

 

And then post the NUT Debug Package again next time you get a shutdown, directly on the first boot after the shutdown. The BX series is known to be bugged (we spoke on GitHub about this) but it shouldn't cause any shutdowns, at least it didn't for any of the other affected people so far. NUT should in general never cause unclean shutdowns (and parity checks) unless something on your server was taking extremely long to stop - resulting in a forced shutdown (but this would also happen without NUT if you press "Shutdown" and something gets stuck). So even if your UPS reported a false power event the shutdown should always have been a clean shutdown. In any case we would need the logs from before the shutdown to really diagnose the problem that led to the unclean shutdown so this is guesswork on my part at best.

 

Regarding the other problems now having stopped on another USB port, I'm guessing the USB port you were previously connecting your UPS to is maybe faulty or the USB cable between the PC and the UPS is in the process of dying. There's a lot of USB related events in the logs, so I'd monitor the situation and if it happens again on the new USB port I'd consider exchanging the cable (can be found on Amazon for around 10$). Sorry I can't really help more at this point, but do report back with new logs in case it happens again.

 

Thanks for the swift reply! I believe copy syslog to flash on shutdown was enabled already, but it seemed that the copying didn't actually happen before the unclean shutdown. Like I mentioned, this morning I moved the USB cable between the UPS and server to another port (USB 3.2 vs 2.0 if that matters) and I haven't had a single error since then (no messages about low batteries either except for a single one right after starting NUT, in fact). Perhaps the port was the problem...

2 minutes ago, KillianMelsen said:

Thanks for the swift reply! I believe copy syslog to flash on shutdown was enabled already, but it seemed that the copying didn't actually happen before the unclean shutdown. Like I mentioned, this morning I moved the USB cable between the UPS and server to another port (USB 3.2 vs 2.0 if that matters) and I haven't had a single error since then (no messages about low batteries either except for a single one right after starting NUT, in fact). Perhaps the port was the problem...

 

Some UPS do behave better on USB 2.0 ports, so I usually always connect mine on USB 2.0 where possible. Another affected user reported the BX problems stopped for him all of a sudden and without changing anything around. I still haven't gotten my hands on a BX series device to investigate more, at this point I'm really clueless what the UPS is actually doing when it reports these states.

@Rysz 

It possible to generate a release with debug symbols, by using https://github.com/networkupstools/nut/pull/2310/files ?


I'm currently getting "Segmentation fault" when starting the driver for my UPS.

It uses SEC protocol via gametronic driver.
The manufacturer does not officially support nut, but he told me that I should configure the serial connection to:

- Baud rate: 2400;
- Data bits: 8;
- Stop bits: 1;
- Parity: None;
- Minimum request interval: 600ms;

This is my manual attempt to debug the error:
 

root@f:/tmp/aaa# /usr/sbin/upsdrvctl -FF -DDDDD -u root start
Network UPS Tools - UPS driver controller 2.8.2
   0.000000     [D2] 
If you're not a NUT core developer, chances are that you're told to enable debugging
to see why a driver isn't working for you. We're sorry for the confusion, but this is
the 'upsdrvctl' wrapper, not the driver you're interested in.

Below you'll find one or more lines starting with 'exec:' followed by an absolute
path to the driver binary and some command line option. This is what the driver
starts and you need to copy and paste that line and append the debug flags to that
line (less the 'exec:' prefix).

Alternately, provide an additional '-d' (lower-case) parameter to 'upsdrvctl' to
pass its current debug level to the launched driver, and '-B' keeps it backgrounded.

   0.000041     [D1] upsdrvctl commanding all drivers (1 found): (null)
   0.000045     [D1] Starting UPS: nhs
   0.000052     [D2] 1 remaining attempts
   0.000056     [D2] exec:  /usr/libexec/nut/gamatronic -FF -a nhs -u root
   0.000059     [D1] Starting the only driver with explicitly requested foregrounding mode, not forking
Network UPS Tools - Gamatronic UPS driver 0.05 (2.8.2)
Connected to UPS on /dev/ttyACM0 baudrate: 2400
UPS: NHS Sistemas de Energia PDV Senoidal 1500 VA
Segmentation fault

I'm wondering if a version with debug symbos included might make it easier to discover the cause of errors and thus perhaps obtain minimal information so that I can open an issue in NUT
 

here I am again with a new problem, after the various low battery nut now freezes and remains at the same wattage for days, I have to restart it manually to fix it but after a while it continues to freeze

It's a big problem because it doesn't seem to communicate with the UPS (which is new, less than a month old) and therefore if there was a blackout it wouldn't do its job

nut-debug-20240416210804.zip

Edited April 16, 20242 yr by PilaScat

48 minutes ago, PilaScat said:

here I am again with a new problem, after the various low battery nut now freezes and remains at the same wattage for days, I have to restart it manually to fix it but after a while it continues to freeze

It's a big problem because it doesn't seem to communicate with the UPS (which is new, less than a month old) and therefore if there was a blackout it wouldn't do its job

nut-debug-20240416210804.zip 241.76 kB · 0 downloads

 

There's lots of USB disconnects in your logs and it seems something is hibernating your UPS periodically - causing the data staleness. I also see you have powertop installed, which is known to cause such issues. Would be best to remove anything powertop related, reboot the system and watch if the problems come back.

11 hours ago, Rysz said:

 

There's lots of USB disconnects in your logs and it seems something is hibernating your UPS periodically - causing the data staleness. I also see you have powertop installed, which is known to cause such issues. Would be best to remove anything powertop related, reboot the system and watch if the problems come back.

strange on powertop there is nothing USB related enabled, however, in theory if I uninstall it and restart, any changes will go back to default, right?

12 minutes ago, PilaScat said:

strange on powertop there is nothing USB related enabled, however, in theory if I uninstall it and restart, any changes will go back to default, right?

 

Yes, if you remove the powertop package from /boot/extra or wherever you placed it, things will revert to default on reboot.

@Rysz How are you compiling NUT? I looked for compilation docs and/or scripts or anything similar in the repository https://github.com/desertwitch/NUT-unRAID, but I couldn't find them.

My plan is to compile NUT from source using Slackware 15 (or Unraid itself), and include some debug configuration ( ./autogen.sh; ./configure --with-debuginfo=auto <other-args> )  and extra stuff to maybe figure out why I'm getting segmentation fault in Unraid.

In other words, I want to compile NUT in a way compatible with your plugin.

The interesting thing is that I compiled nut from the source code in Ubuntu 22.04 and the gametronic driver does not raise an segmentation fault and works as expected.

Edited April 18, 20242 yr by luzfcb

51 minutes ago, luzfcb said:

@Rysz How are you compiling NUT? I looked for compilation docs and/or scripts or anything similar in the repository https://github.com/desertwitch/NUT-unRAID, but I couldn't find them.

My plan is to compile NUT from source using Slackare 15 (or Unraid itself), and include some debug configuration ( ./autogen.sh; ./configure --with-debuginfo=auto <other-args> )  and extra stuff to maybe figure out why I'm getting segmentation fault in Unraid.

In other words, I want to compile NUT in a way compatible with your plugin.

The interesting thing is that I compiled nut from the source code in Ubuntu 22.04 and the gametronic driver does not raise an segmentation fault and works as expected.

 

I've compiled a package for you... 🙂 

From current Git master with all debug symbols included and also --with-debuginfo.

 

You can install it on your Unraid system as follows:

1. Stop NUT in NUT Settings
2. cd /var/log/packages
3. removepkg nut-2.8.2* (make sure to uninstall only nut, not nut-plugin)
4. Put the debug package somewhere on your system (e.g /root/)
5. cd /root
6. installpkg nut-2.8.2-x86_64-1debug.txz
7. Start NUT in NUT Settings or directly start driver for debugging (as above)

nut-2.8.2-x86_64-1debug.txz

 

You can find the build scripts in the packages themselves under /usr/src/nut-2.8.2/nut.SlackBuild

Please let me know what debugging information is shown for the segmentation fault, I'm curious too.

 

Probably also worthwhile to raise the debug level on the driver with -DDDDDD

 

Edited April 18, 20242 yr by Rysz

On 4/17/2024 at 10:00 AM, Rysz said:

 

Yes, if you remove the powertop package from /boot/extra or wherever you placed it, things will revert to default on reboot.

Did it but same problem, not changed anything other then uninstalling powertop

nut-debug-20240419001806.zip

Hi I'm trying to set this up for the first time - setting this up as slave...

 

1. There is a small red hand near the monitoring password - why is that the case?

2. If I try to enable the service I see the below. Not sure what to make of any of the lines

 

Apr 19 12:26:24 HomeServer rc.nut: Writing NUT configuration...
Apr 19 12:26:27 HomeServer rc.nut: Updating permissions for NUT...
Apr 19 12:26:27 HomeServer rc.nut: Checking if the NUT Runtime Statistics Module should be enabled...
Apr 19 12:26:27 HomeServer rc.nut: Disabling the NUT Runtime Statistics Module...
Apr 19 12:26:28 HomeServer rc.nut: fopen /var/run/nut/upsmon.pid: No such file or directory
Apr 19 12:26:28 HomeServer rc.nut: Could not find PID file to see if previous upsmon instance is already running!
Apr 19 12:26:28 HomeServer rc.nut: Unable to use old-style MONITOR line without a username
Apr 19 12:26:28 HomeServer rc.nut: Convert it and add a username to upsd.users - see the documentation
Apr 19 12:26:28 HomeServer rc.nut: Fatal error: unusable configuration

 

2 minutes ago, andyd said:

Hi I'm trying to set this up for the first time - setting this up as slave...

 

1. There is a small red hand near the monitoring password - why is that the case?

2. If I try to enable the service I see the below. Not sure what to make of any of the lines

 

Apr 19 12:26:24 HomeServer rc.nut: Writing NUT configuration...
Apr 19 12:26:27 HomeServer rc.nut: Updating permissions for NUT...
Apr 19 12:26:27 HomeServer rc.nut: Checking if the NUT Runtime Statistics Module should be enabled...
Apr 19 12:26:27 HomeServer rc.nut: Disabling the NUT Runtime Statistics Module...
Apr 19 12:26:28 HomeServer rc.nut: fopen /var/run/nut/upsmon.pid: No such file or directory
Apr 19 12:26:28 HomeServer rc.nut: Could not find PID file to see if previous upsmon instance is already running!
Apr 19 12:26:28 HomeServer rc.nut: Unable to use old-style MONITOR line without a username
Apr 19 12:26:28 HomeServer rc.nut: Convert it and add a username to upsd.users - see the documentation
Apr 19 12:26:28 HomeServer rc.nut: Fatal error: unusable configuration

 

 

The monitor password is using incompatible special characters, that's also why you're getting the error and red hand. Change it to something simpler on the master, best without special characters at all, and then use that on the slave as well and it should work. 🙂 Please report back if that solved your problem.

2 hours ago, Rysz said:

 

The monitor password is using incompatible special characters, that's also why you're getting the error and red hand. Change it to something simpler on the master, best without special characters at all, and then use that on the slave as well and it should work. 🙂 Please report back if that solved your problem.

 

That did address it ... thanks! Can't communicate with the server but I think this has to do with Opnsense where the nut server lives. I'll have to check on that

On 4/20/2024 at 12:09 AM, andyd said:

 

That did address it ... thanks! Can't communicate with the server but I think this has to do with Opnsense where the nut server lives. I'll have to check on that

 

On most firewalls (like pfSense) you need to open the port 3493 from/to LAN devices.

NUT keeps failing on startup. I suspect it's due to high CPU load - as home assistant is also failing on startup since I installed NUT. I'd really just like to add a delay to startup, but if anyone can see anything else that could cause it, see the attached debug package. (I dragged the debug folder as 1 folder and it seems to have submitted it as many different files.. sorry about that)

BazansUPS.dev.txt nut-dw.cfg.txt nut-dw.plg.txt nut-scanner.txt nut.conf.txt ups.conf.txt upsd.conf.txt upsd.users.txt upsmon.conf.txt upssched.conf.txt xnut-nospam.conf.txt tower-diagnostics-20240423-1343.zip unraid-lsusb.txt unraid-packages.txt unraid-version.txt nut.conf.txt ups.conf.txt upsd.conf.txt upsd.users.txt upsmon.conf.txt upssched.conf.txt xnut-nospam.conf.txt

17 minutes ago, PartyingChair said:

NUT keeps failing on startup. I suspect it's due to high CPU load - as home assistant is also failing on startup since I installed NUT. I'd really just like to add a delay to startup, but if anyone can see anything else that could cause it, see the attached debug package. (I dragged the debug folder as 1 folder and it seems to have submitted it as many different files.. sorry about that)

BazansUPS.dev.txt 1 kB · 0 downloads nut-dw.cfg.txt 1.15 kB · 0 downloads nut-dw.plg.txt 33.08 kB · 0 downloads nut-scanner.txt 524 B · 1 download nut.conf.txt 126 B · 0 downloads ups.conf.txt 198 B · 1 download upsd.conf.txt 34 B · 0 downloads upsd.users.txt 325 B · 0 downloads upsmon.conf.txt 391 B · 0 downloads upssched.conf.txt 20 B · 0 downloads xnut-nospam.conf.txt 1.04 kB · 0 downloads tower-diagnostics-20240423-1343.zip 146.33 kB · 1 download unraid-lsusb.txt 1.85 kB · 0 downloads unraid-packages.txt 115 B · 0 downloads unraid-version.txt 18 B · 0 downloads nut.conf.txt 126 B · 0 downloads ups.conf.txt 198 B · 0 downloads upsd.conf.txt 34 B · 0 downloads upsd.users.txt 325 B · 0 downloads upsmon.conf.txt 391 B · 0 downloads upssched.conf.txt 20 B · 0 downloads xnut-nospam.conf.txt 1.04 kB · 0 downloads

 

It seems your UPS takes longer to get ready for a USB connection than it should.

I'm not sure what is causing this, as a workaround you can put this in your /boot/config/go file:

at now + 3 minutes <<< "/etc/rc.d/rc.nut restart 2>&1 | logger"

Which will restart the NUT services 3 minutes after system boot and it should be ready by then.

You can also try before on another USB port or with another USB cable, that could also help. 🙂 

 

Edited April 23, 20242 yr by Rysz