Might be very simple, but how do I enabled beeping? I found:

 but I cannot find the mentioned username/password anywhere...

24 minutes ago, KillianMelsen said:

Might be very simple, but how do I enabled beeping? I found:

 but I cannot find the mentioned username/password anywhere...

 

It's inside the upsd.users configuration file (see below - admin/adminpass):

As outlined in the linked post it can be done using upscmd, if your UPS supports this. Otherwise it can usually be easier set directly on the UPS, either via physical button or LCD panel (check manual about this for your UPS).

 

Edited July 16, 20241 yr by Rysz

Hi,

I'm back after a few months 😆

Had a power cut 2 days ago and weird stuff happened again... since the last time, i added a old raspberry pi to manage the UPS separately so i wouldn't be blind if my server went off.

If i have my settings correct (attached print), the server should wait till it only has 300s/5min of battery left to initiate shutdown,.

Also attached the logging for the UPS.

The server decided to shut down at around 11:45:50, at that time it had around ~1000s left of runtime...

Not sure if I'm doing something wrong, or there's still some bug around 😅
I was getting into a theory that it initiated shutdown after 300s, but the math doesn't add up very well, assuming the worst case that it switched to OB at 11:43:02, since it powered off at 11:45:50... that would be at most 3min/180s 🤔
Any ideas? I can try to debug stuff if needed starting on 28th of july.

 

 

 

2 hours ago, danielb7390 said:

Hi,

I'm back after a few months 😆

Had a power cut 2 days ago and weird stuff happened again... since the last time, i added a old raspberry pi to manage the UPS separately so i wouldn't be blind if my server went off.

If i have my settings correct (attached print), the server should wait till it only has 300s/5min of battery left to initiate shutdown,.

Also attached the logging for the UPS.

The server decided to shut down at around 11:45:50, at that time it had around ~1000s left of runtime...

Not sure if I'm doing something wrong, or there's still some bug around 😅
I was getting into a theory that it initiated shutdown after 300s, but the math doesn't add up very well, assuming the worst case that it switched to OB at 11:43:02, since it powered off at 11:45:50... that would be at most 3min/180s 🤔
Any ideas? I can try to debug stuff if needed starting on 28th of july.

 

 

 

 

Please post the NUT Debug Package that can be found on NUT Settings page.

1 minute ago, Rysz said:

 

Please post the NUT Debug Package that can be found on NUT Settings page.

Sorry, forgot.

nut-debug-20240717113624.zip

2 minutes ago, danielb7390 said:

Sorry, forgot.

nut-debug-20240717113624.zip 112.73 kB · 0 downloads

 

Thanks, unfortunately there's no pre-shutdown logfiles anymore - so it's hard to say what happened exactly. In NUT slave mode it's however also dependent on the NUT master's shutdown criteria, because if the NUT master is configured any different and starts a shutdown, that will also take down the NUT slaves (even if the criteria on the slaves has not been met yet). Are there any different shutdown criteria set on the NUT master (the RPi) that would explain why a shutdown could have been initiated? Also, was it an unclean shutdown that triggered a parity check after booting up again or just a "regular" graceful shutdown as it should normally have been triggered by NUT (just it had been triggered prematurely)? The only real chance at finding the culprit would be that you set up the SYSLOG server so that the pre-shutdown logs do not get lost. Then we can work with those logs and will see messages from NUT saying why it decided to shutdown, everything else is just guesswork I'm afraid.

Just checked the Rpi dmesg, if I'm not mistaken nut prints stuff in here right?

Just found this... that might be a bit worrying too, but the timestamps don't seem to match with the power off time.

[Mon Jul 15 11:48:54 2024] usb 1-1.3: usbfs: USBDEVFS_CONTROL failed cmd usbhid-ups rqt 161 rq 1 len 3 ret -110
[Mon Jul 15 11:48:55 2024] usb 1-1.3: USB disconnect, device number 10
[Mon Jul 15 11:48:55 2024] usb 1-1.3: new full-speed USB device number 11 using dwc_otg
[Mon Jul 15 11:48:56 2024] usb 1-1.3: New USB device found, idVendor=0463, idProduct=ffff, bcdDevice= 0.01
[Mon Jul 15 11:48:56 2024] usb 1-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[Mon Jul 15 11:48:56 2024] usb 1-1.3: Product: 5E
[Mon Jul 15 11:48:56 2024] usb 1-1.3: Manufacturer: EATON
[Mon Jul 15 11:48:58 2024] hid-generic 0003:0463:FFFF.0008: hiddev96,hidraw0: USB HID v1.10 Device [EATON 5E] on usb-20980000.usb-1.3/input0
[Mon Jul 15 12:06:08 2024] usb 1-1.3: usbfs: USBDEVFS_CONTROL failed cmd usbhid-ups rqt 161 rq 1 len 3 ret -110
[Mon Jul 15 12:06:09 2024] usb 1-1.3: USB disconnect, device number 11
[Mon Jul 15 12:06:10 2024] usb 1-1.3: new full-speed USB device number 12 using dwc_otg
[Mon Jul 15 12:06:10 2024] usb 1-1.3: New USB device found, idVendor=0463, idProduct=ffff, bcdDevice= 0.01
[Mon Jul 15 12:06:10 2024] usb 1-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[Mon Jul 15 12:06:10 2024] usb 1-1.3: Product: 5E
[Mon Jul 15 12:06:10 2024] usb 1-1.3: Manufacturer: EATON
[Mon Jul 15 12:06:12 2024] hid-generic 0003:0463:FFFF.0009: hiddev96,hidraw0: USB HID v1.10 Device [EATON 5E] on usb-20980000.usb-1.3/input0

 

Rpi nut services

service --status-all | grep nut
 [ - ]  nut-client
 [ + ]  nut-server

 

Rpi Cfgs

# /etc/nut/nut.conf
MODE=netserver

# /etc/nut/ups.conf
maxretry = 3
[ups]
  driver = usbhid-ups
  port = auto

# /etc/nut/upsd.conf
LISTEN 0.0.0.0 3493

# /etc/nut/upsd.users

# /etc/nut/upsmon.conf
MINSUPPLIES 1
SHUTDOWNCMD "/sbin/shutdown -h +0"
POLLFREQ 5
POLLFREQALERT 5
HOSTSYNC 15
DEADTIME 15
POWERDOWNFLAG /etc/killpower
RBWARNTIME 43200
NOCOMMWARNTIME 300
FINALDELAY 5

# /etc/nut/upssched.conf
CMDSCRIPT /bin/upssched-cmd

 

Do you see anything clearly wrong here?
Does the plugin have any way to enable debug or something and prevent shutdown?

8 minutes ago, danielb7390 said:

Just checked the Rpi dmesg, if I'm not mistaken nut prints stuff in here right?

Just found this... that might be a bit worrying too, but the timestamps don't seem to match with the power off time.

[Mon Jul 15 11:48:54 2024] usb 1-1.3: usbfs: USBDEVFS_CONTROL failed cmd usbhid-ups rqt 161 rq 1 len 3 ret -110
[Mon Jul 15 11:48:55 2024] usb 1-1.3: USB disconnect, device number 10
[Mon Jul 15 11:48:55 2024] usb 1-1.3: new full-speed USB device number 11 using dwc_otg
[Mon Jul 15 11:48:56 2024] usb 1-1.3: New USB device found, idVendor=0463, idProduct=ffff, bcdDevice= 0.01
[Mon Jul 15 11:48:56 2024] usb 1-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[Mon Jul 15 11:48:56 2024] usb 1-1.3: Product: 5E
[Mon Jul 15 11:48:56 2024] usb 1-1.3: Manufacturer: EATON
[Mon Jul 15 11:48:58 2024] hid-generic 0003:0463:FFFF.0008: hiddev96,hidraw0: USB HID v1.10 Device [EATON 5E] on usb-20980000.usb-1.3/input0
[Mon Jul 15 12:06:08 2024] usb 1-1.3: usbfs: USBDEVFS_CONTROL failed cmd usbhid-ups rqt 161 rq 1 len 3 ret -110
[Mon Jul 15 12:06:09 2024] usb 1-1.3: USB disconnect, device number 11
[Mon Jul 15 12:06:10 2024] usb 1-1.3: new full-speed USB device number 12 using dwc_otg
[Mon Jul 15 12:06:10 2024] usb 1-1.3: New USB device found, idVendor=0463, idProduct=ffff, bcdDevice= 0.01
[Mon Jul 15 12:06:10 2024] usb 1-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[Mon Jul 15 12:06:10 2024] usb 1-1.3: Product: 5E
[Mon Jul 15 12:06:10 2024] usb 1-1.3: Manufacturer: EATON
[Mon Jul 15 12:06:12 2024] hid-generic 0003:0463:FFFF.0009: hiddev96,hidraw0: USB HID v1.10 Device [EATON 5E] on usb-20980000.usb-1.3/input0

 

Rpi nut services

service --status-all | grep nut
 [ - ]  nut-client
 [ + ]  nut-server

 

Rpi Cfgs

# /etc/nut/nut.conf
MODE=netserver

# /etc/nut/ups.conf
maxretry = 3
[ups]
  driver = usbhid-ups
  port = auto

# /etc/nut/upsd.conf
LISTEN 0.0.0.0 3493

# /etc/nut/upsd.users

# /etc/nut/upsmon.conf
MINSUPPLIES 1
SHUTDOWNCMD "/sbin/shutdown -h +0"
POLLFREQ 5
POLLFREQALERT 5
HOSTSYNC 15
DEADTIME 15
POWERDOWNFLAG /etc/killpower
RBWARNTIME 43200
NOCOMMWARNTIME 300
FINALDELAY 5

# /etc/nut/upssched.conf
CMDSCRIPT /bin/upssched-cmd

 

Do you see anything clearly wrong here?
Does the plugin have any way to enable debug or something and prevent shutdown?

 

dmesg is just the kernel ring buffer, you won't find NUT's messages in there (just device-related ones).
These connection messages are not worrying in particular, just some minor hiccups which are common.

 

NUT would output the messages to /var/log/syslog - both on Unraid and the RPi.

Can you check if the RPi has any NUT-related messages in /var/log/syslog from that time?

On Unraid itself you'd need to turn on the SYSLOG server to preserve these messages over reboot.

 

Edited July 17, 20241 yr by Rysz

2 minutes ago, Rysz said:

 

dmesg is just the kernel ring buffer, you won't find NUT's messages in there (just device-related ones).

 

NUT would output the messages to /var/log/syslog - both on Unraid and the RPi.

Can you check if the RPi has any NUT-related messages in /var/log/syslog from that time?

 

On Unraid itself you'd need to turn on the SYSLOG server to preserve these messages over reboot.

/var/log/syslog from the Rpi

Jul 15 12:45:09 pvznut kernel: [5610659.453738] usb 1-1.3: usbfs: USBDEVFS_CONTROL failed cmd usbhid-ups rqt 161 rq 1 len 3 ret -110
Jul 15 12:45:10 pvznut kernel: [5610660.485979] usb 1-1.3: USB disconnect, device number 10
Jul 15 12:45:10 pvznut kernel: [5610660.893728] usb 1-1.3: new full-speed USB device number 11 using dwc_otg
Jul 15 12:45:11 pvznut usbhid-ups[361]: libusb_get_interrupt: error submitting URB: No such device
Jul 15 12:45:11 pvznut kernel: [5610661.641961] usb 1-1.3: New USB device found, idVendor=0463, idProduct=ffff, bcdDevice= 0.01
Jul 15 12:45:11 pvznut kernel: [5610661.642025] usb 1-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=0
Jul 15 12:45:11 pvznut kernel: [5610661.642050] usb 1-1.3: Product: 5E
Jul 15 12:45:11 pvznut kernel: [5610661.642068] usb 1-1.3: Manufacturer: EATON
Jul 15 12:45:13 pvznut upsd[363]: Data for UPS [ups] is stale - check driver
Jul 15 12:45:13 pvznut kernel: [5610663.624947] hid-generic 0003:0463:FFFF.0008: hiddev96,hidraw0: USB HID v1.10 Device [EATON 5E] on usb-20980000.usb-1.3/input0
Jul 15 12:45:13 pvznut mtp-probe: checking bus 1, device 11: "/sys/devices/platform/soc/20980000.usb/usb1/1-1/1-1.3"
Jul 15 12:45:13 pvznut mtp-probe: bus: 1, device: 11 was not an MTP device
Jul 15 12:45:13 pvznut mtp-probe: checking bus 1, device 11: "/sys/devices/platform/soc/20980000.usb/usb1/1-1/1-1.3"
Jul 15 12:45:13 pvznut mtp-probe: bus: 1, device: 11 was not an MTP device
Jul 15 12:45:16 pvznut upsd[363]: UPS [ups] data is no longer stale
Jul 15 13:02:23 pvznut kernel: [5611693.655502] usb 1-1.3: usbfs: USBDEVFS_CONTROL failed cmd usbhid-ups rqt 161 rq 1 len 3 ret -110
Jul 15 13:02:24 pvznut kernel: [5611694.729648] usb 1-1.3: USB disconnect, device number 11
Jul 15 13:02:24 pvznut kernel: [5611695.085298] usb 1-1.3: new full-speed USB device number 12 using dwc_otg
Jul 15 13:02:25 pvznut usbhid-ups[361]: libusb_get_interrupt: error submitting URB: No such device
Jul 15 13:02:25 pvznut kernel: [5611695.833970] usb 1-1.3: New USB device found, idVendor=0463, idProduct=ffff, bcdDevice= 0.01
Jul 15 13:02:25 pvznut kernel: [5611695.834035] usb 1-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=0
Jul 15 13:02:25 pvznut kernel: [5611695.834061] usb 1-1.3: Product: 5E
Jul 15 13:02:25 pvznut kernel: [5611695.834080] usb 1-1.3: Manufacturer: EATON
Jul 15 13:02:27 pvznut upsd[363]: Data for UPS [ups] is stale - check driver
Jul 15 13:02:27 pvznut kernel: [5611697.816452] hid-generic 0003:0463:FFFF.0009: hiddev96,hidraw0: USB HID v1.10 Device [EATON 5E] on usb-20980000.usb-1.3/input0
Jul 15 13:02:27 pvznut mtp-probe: checking bus 1, device 12: "/sys/devices/platform/soc/20980000.usb/usb1/1-1/1-1.3"
Jul 15 13:02:27 pvznut mtp-probe: bus: 1, device: 12 was not an MTP device
Jul 15 13:02:28 pvznut mtp-probe: checking bus 1, device 12: "/sys/devices/platform/soc/20980000.usb/usb1/1-1/1-1.3"
Jul 15 13:02:28 pvznut mtp-probe: bus: 1, device: 12 was not an MTP device
Jul 15 13:02:30 pvznut upsd[363]: UPS [ups] data is no longer stale

 

Thanks for the help, even tho this can possibly be outside of the scope of the plugin.
Probably of no help tho, will have to set the syslog next week and test with a simulated power outage to get some data...

2 minutes ago, danielb7390 said:

/var/log/syslog from the Rpi

Jul 15 12:45:09 pvznut kernel: [5610659.453738] usb 1-1.3: usbfs: USBDEVFS_CONTROL failed cmd usbhid-ups rqt 161 rq 1 len 3 ret -110
Jul 15 12:45:10 pvznut kernel: [5610660.485979] usb 1-1.3: USB disconnect, device number 10
Jul 15 12:45:10 pvznut kernel: [5610660.893728] usb 1-1.3: new full-speed USB device number 11 using dwc_otg
Jul 15 12:45:11 pvznut usbhid-ups[361]: libusb_get_interrupt: error submitting URB: No such device
Jul 15 12:45:11 pvznut kernel: [5610661.641961] usb 1-1.3: New USB device found, idVendor=0463, idProduct=ffff, bcdDevice= 0.01
Jul 15 12:45:11 pvznut kernel: [5610661.642025] usb 1-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=0
Jul 15 12:45:11 pvznut kernel: [5610661.642050] usb 1-1.3: Product: 5E
Jul 15 12:45:11 pvznut kernel: [5610661.642068] usb 1-1.3: Manufacturer: EATON
Jul 15 12:45:13 pvznut upsd[363]: Data for UPS [ups] is stale - check driver
Jul 15 12:45:13 pvznut kernel: [5610663.624947] hid-generic 0003:0463:FFFF.0008: hiddev96,hidraw0: USB HID v1.10 Device [EATON 5E] on usb-20980000.usb-1.3/input0
Jul 15 12:45:13 pvznut mtp-probe: checking bus 1, device 11: "/sys/devices/platform/soc/20980000.usb/usb1/1-1/1-1.3"
Jul 15 12:45:13 pvznut mtp-probe: bus: 1, device: 11 was not an MTP device
Jul 15 12:45:13 pvznut mtp-probe: checking bus 1, device 11: "/sys/devices/platform/soc/20980000.usb/usb1/1-1/1-1.3"
Jul 15 12:45:13 pvznut mtp-probe: bus: 1, device: 11 was not an MTP device
Jul 15 12:45:16 pvznut upsd[363]: UPS [ups] data is no longer stale
Jul 15 13:02:23 pvznut kernel: [5611693.655502] usb 1-1.3: usbfs: USBDEVFS_CONTROL failed cmd usbhid-ups rqt 161 rq 1 len 3 ret -110
Jul 15 13:02:24 pvznut kernel: [5611694.729648] usb 1-1.3: USB disconnect, device number 11
Jul 15 13:02:24 pvznut kernel: [5611695.085298] usb 1-1.3: new full-speed USB device number 12 using dwc_otg
Jul 15 13:02:25 pvznut usbhid-ups[361]: libusb_get_interrupt: error submitting URB: No such device
Jul 15 13:02:25 pvznut kernel: [5611695.833970] usb 1-1.3: New USB device found, idVendor=0463, idProduct=ffff, bcdDevice= 0.01
Jul 15 13:02:25 pvznut kernel: [5611695.834035] usb 1-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=0
Jul 15 13:02:25 pvznut kernel: [5611695.834061] usb 1-1.3: Product: 5E
Jul 15 13:02:25 pvznut kernel: [5611695.834080] usb 1-1.3: Manufacturer: EATON
Jul 15 13:02:27 pvznut upsd[363]: Data for UPS [ups] is stale - check driver
Jul 15 13:02:27 pvznut kernel: [5611697.816452] hid-generic 0003:0463:FFFF.0009: hiddev96,hidraw0: USB HID v1.10 Device [EATON 5E] on usb-20980000.usb-1.3/input0
Jul 15 13:02:27 pvznut mtp-probe: checking bus 1, device 12: "/sys/devices/platform/soc/20980000.usb/usb1/1-1/1-1.3"
Jul 15 13:02:27 pvznut mtp-probe: bus: 1, device: 12 was not an MTP device
Jul 15 13:02:28 pvznut mtp-probe: checking bus 1, device 12: "/sys/devices/platform/soc/20980000.usb/usb1/1-1/1-1.3"
Jul 15 13:02:28 pvznut mtp-probe: bus: 1, device: 12 was not an MTP device
Jul 15 13:02:30 pvznut upsd[363]: UPS [ups] data is no longer stale

 

Thanks for the help, even tho this can possibly be outside of the scope of the plugin.
Probably of no help tho, will have to set the syslog next week and test with a simulated power outage to get some data...

 

Nothing there that says a shutdown was in fact triggered by anything. USB disconnects and related data staleness seems to occur relatively frequently but was recovered from within a few seconds in these visible cases. Longer lasting data staleness can cause either the NUT master or NUT slaves to consider a UPS as non-communicating and critical (resulting in a shutdown), but I'm not seeing that in the logs here either. We'll have to try with the SYSLOG server on Unraid to get more clarity on what is happening during such OB situations, unless you see anything in the RPi logs from around that time regarding NUT status changes or any shutdowns being initiated. NUT is usually very talkative, so it would write any such major events in the logs.

Well, had another power failure one today, and this time it correctly powered off when there was 5 minutes remaining.

So, it seems it's going to be one of those annoying bugs that happen only when nobody is looking 😆

46 minutes ago, danielb7390 said:

Well, had another power failure one today, and this time it correctly powered off when there was 5 minutes remaining.

So, it seems it's going to be one of those annoying bugs that happen only when nobody is looking 😆

 

That being said, "Runtime Left" is the least reliable of the three shutdown modes. The runtime reported by the UPS and the actual possible battery runtime can fluctuate and vary a lot depending on both the battery health and the implementation of the calculation mechanism in the UPS. I generally recommend to use "Time on Battery" or "Battery Level" as more reliable mechanisms. My UPS - for example - are set to shutdown after 2 minutes on battery, as by that time usually a recovery of the mains power is no longer to be expected (if it doesn't recover within 2 minutes it's usually down for a lot longer than the UPS could cover).

 

Edited July 20, 20241 yr by Rysz

5 hours ago, danielb7390 said:

it correctly powered off when there was 5 minutes remaining.

If the UPS is using typical SLA batteries, draining below 50% capacity regularly will wear them out sooner.

Ideally you should shut down quickly, as soon as you can be sure the power won't come back for several minutes.

https://www.power-sonic.com/wp-content/uploads/2018/12/Technical-Manual.pdf#page=12

On 7/14/2024 at 10:05 PM, Rysz said:

Hello!

 

This is unfortunately the result of minor driver connection instabilities, nothing we can do about it.

It's good that everything else works normally though, so you can just filter out these SYSLOG messages.

 

1) Put these lines at the end of xnut-nospam.conf using NUT Configuration Editor in GUI:

:msg, regex, "nut_libusb_get.*Input/Output Error" -/var/log/nut-spam
:msg, regex, "nut_libusb_get.*Input/Output Error" stop

 

2) So it will look like this - click "Save":

 

3) Set "Enable Rule-Based Syslog Filters:" to "Yes" in NUT Settings:

 

4) Click "Apply" and these messages should now no longer appear in your SYSLOG.

Please note this will only be applied to new messages, the old ones will still be visible in SYSLOG.

 

Please let me know if that worked for you! 🙂 

 

 

Hello,

I had the same issue and tried your above fix but this did not stop the error messages.  do you have another idea or maybe why it wouldnt work for me?  thank you!

13 hours ago, knights_of_pine said:

 

 

Hello,

I had the same issue and tried your above fix but this did not stop the error messages.  do you have another idea or maybe why it wouldnt work for me?  thank you!

 

Please post the NUT Debug Package that can be found in NUT Settings.

On 7/20/2024 at 11:12 PM, Rysz said:

 

Please post the NUT Debug Package that can be found in NUT Settings.

what part of the nut debug package would you like me to post?

2 hours ago, knights_of_pine said:

what part of the nut debug package would you like me to post?

 

The whole one, otherwise I won't be able to help you...

Hi,

The plugin has "On Battery" status for me and is not showing any values. When using the built-in UPS option I do see it connected correctly and do see the values, however, the USB connection was being lost after a day or so each time. I have switched the cable and used a different port but still getting the same result. I have attached the debug. Any advice? Thanks

nut-debug-20240723182403.zip

2 hours ago, bnbg said:

Hi,

The plugin has "On Battery" status for me and is not showing any values. When using the built-in UPS option I do see it connected correctly and do see the values, however, the USB connection was being lost after a day or so each time. I have switched the cable and used a different port but still getting the same result. I have attached the debug. Any advice? Thanks

nut-debug-20240723182403.zip 203.03 kB · 0 downloads

Your UPS is not listed as compatible to NUT, however you can try "Auto Config" if that improves anything.

Otherwise you can try opening a ticket here: https://github.com/networkupstools/nut/issues

But I haven't found anyone on the internet who's used your UPS in combination with NUT so far.

54 minutes ago, Rysz said:

Your UPS is not listed as compatible to NUT, however you can try "Auto Config" if that improves anything.

Otherwise you can try opening a ticket here: https://github.com/networkupstools/nut/issues

But I haven't found anyone on the internet who's used your UPS in combination with NUT so far.

I tried auto config but still no joy, unfortunately.

I will log a ticket there. Is there anything else I can do to help get it compatible/supported? 

On 7/22/2024 at 9:26 PM, Rysz said:

 

The whole one, otherwise I won't be able to help you...

please see attached.  thank you!

nut-debug-20240725192957.zip

2 hours ago, knights_of_pine said:

please see attached.  thank you!

nut-debug-20240725192957.zip 313.18 kB · 1 download

 

Change your xnut-nospam.conf via GUI configuration editor (in NUT Settings) so it looks like this:

#
# DO NOT CHANGE THIS FILE IF YOU DO NOT KNOW WHAT YOU ARE DOING
# CHANGING THIS FILE CAN BREAK YOUR ENTIRE SYSTEM LOGGING CAPABILITIES
# MAKING IT ALMOST IMPOSSIBLE FOR OTHERS TO HELP YOU IN CASE OF PROBLEMS
#
# NUT Rule-Based Repetitive Message Filtering (SYSLOG Anti-Spam Module)
# https://www.rsyslog.com/doc/configuration/filters.html
# https://www.rsyslog.com/doc/configuration/actions.html
#
# When adding new rules, be as specific as possible and filter as little
# as just possible in order not to discard important diagnostic information
# from both the SYSLOG itself and any otherwise generated diagnostic packages
#

:msg, regex, "UPS.*data is no longer stale" -/var/log/nut-spam
:msg, regex, "UPS.*Data stale" -/var/log/nut-spam
:msg, regex, "Communications with UPS.*lost" -/var/log/nut-spam
:msg, regex, "Communications with UPS.*established" -/var/log/nut-spam
:msg, regex, "UPS.*data is no longer stale" stop
:msg, regex, "UPS.*Data stale" stop
:msg, regex, "Communications with UPS.*lost" stop
:msg, regex, "Communications with UPS.*established" stop

:msg, regex, "nut_libusb_get.*Error" -/var/log/nut-spam
:msg, regex, "nut_libusb_get.*Error" stop
:msg, regex, "nut_libusb_get.*error" -/var/log/nut-spam
:msg, regex, "nut_libusb_get.*error" stop

Then restart NUT and the spam lines in log should disappear, can you confirm?

 

On 7/25/2024 at 10:08 PM, Rysz said:

 

Change your xnut-nospam.conf via GUI configuration editor (in NUT Settings) so it looks like this:

#
# DO NOT CHANGE THIS FILE IF YOU DO NOT KNOW WHAT YOU ARE DOING
# CHANGING THIS FILE CAN BREAK YOUR ENTIRE SYSTEM LOGGING CAPABILITIES
# MAKING IT ALMOST IMPOSSIBLE FOR OTHERS TO HELP YOU IN CASE OF PROBLEMS
#
# NUT Rule-Based Repetitive Message Filtering (SYSLOG Anti-Spam Module)
# https://www.rsyslog.com/doc/configuration/filters.html
# https://www.rsyslog.com/doc/configuration/actions.html
#
# When adding new rules, be as specific as possible and filter as little
# as just possible in order not to discard important diagnostic information
# from both the SYSLOG itself and any otherwise generated diagnostic packages
#

:msg, regex, "UPS.*data is no longer stale" -/var/log/nut-spam
:msg, regex, "UPS.*Data stale" -/var/log/nut-spam
:msg, regex, "Communications with UPS.*lost" -/var/log/nut-spam
:msg, regex, "Communications with UPS.*established" -/var/log/nut-spam
:msg, regex, "UPS.*data is no longer stale" stop
:msg, regex, "UPS.*Data stale" stop
:msg, regex, "Communications with UPS.*lost" stop
:msg, regex, "Communications with UPS.*established" stop

:msg, regex, "nut_libusb_get.*Error" -/var/log/nut-spam
:msg, regex, "nut_libusb_get.*Error" stop
:msg, regex, "nut_libusb_get.*error" -/var/log/nut-spam
:msg, regex, "nut_libusb_get.*error" stop

Then restart NUT and the spam lines in log should disappear, can you confirm?

 

i tried and unfortunately still getting the errors in the log...

 

12 minutes ago, knights_of_pine said:

i tried and unfortunately still getting the errors in the log...

 

 

That's really odd, did you enable the "Rule-based Syslog Filters" in NUT Settings and restart NUT?

If you did, please try restarting NUT again and also run this command if that still doesn't work:

/etc/rc.d/rc.rsyslogd restart

 

25 minutes ago, Rysz said:

 

That's really odd, did you enable the "Rule-based Syslog Filters" in NUT Settings and restart NUT?

If you did, please try restarting NUT again and also run this command if that still doesn't work:

/etc/rc.d/rc.rsyslogd restart

 

unfortunately, no change...