[Plugin] NUT v2 - Network UPS Tools


dmacias

Recommended Posts

On 10/28/2023 at 1:46 PM, Rysz said:

 

Hmm, does it say anything in the logs with the tripplite_usb driver?

 

What else you can try:

  • Auto Config with different USB port
  • Same settings on backend "release (2.8.0 stable)"
  • Same settings on backend "legacy (2.7.4 stable)"
  • Auto Config on backend "release (2.8.0 stable)"
  • Auto Config on backend "legacy (2.7.4 stable)"

If you don't want to reboot changing backends, you can also just uninstall and reinstall the plugin (after changing the backend). Just make sure that "Network UPS Tools Backend:" says something different than before, that it's actually changed (you at least need to reinstall the plugin, otherwise it won't change the backend).

 

 

I finally got around to trying all of this. I still can't connect via autoconfig. Below is the info for the device, is there a way to see if its an access issue with the port?

 

    |__ Port 6: Dev 85, If 0, Class=Human Interface Device, Driver=usbhid, 1.5M
        ID 09ae:3018 Tripp Lite 
        /sys/bus/usb/devices/1-6  /dev/bus/usb/001/085

Link to comment
23 hours ago, scuppasteve said:

 

I finally got around to trying all of this. I still can't connect via autoconfig. Below is the info for the device, is there a way to see if its an access issue with the port?

 

    |__ Port 6: Dev 85, If 0, Class=Human Interface Device, Driver=usbhid, 1.5M
        ID 09ae:3018 Tripp Lite 
        /sys/bus/usb/devices/1-6  /dev/bus/usb/001/085

 

Another user on Discord had more luck pointing the UPS Driver Port directly to the respective /dev/ device assigned to the UPS (in his case e.g. /dev/ttyUSB0) instead of using auto. If you can figure out (e.g. from the logs) which /dev/ device your UPS device was assigned to, you could attempt to point the driver directly to that port instead (try it with both tripplite_usb and usbhid-ups drivers).

 

Looks like in your case that'd be: /dev/bus/usb/001/085

 

Edited by Rysz
Link to comment
On 10/31/2023 at 10:18 PM, Rysz said:

 

If you never had problems before changing then I'd recommend the backend: legacy (2.7.4 stable). Some UPS don't play well with the newer backends, and this is the one the older plugin has also used. Note that you will need to reboot your system for the backend change to become effective.

 

It should then say: "nut-2.7.4.20200318-x86_64-1" for "Network UPS Tools Backend". You will then stay on that backend permanently and updates will only affect the other parts of the plugin (but not the UPS drivers).

 

I moved all my USB devices to different ports. I made sure to plug the UPS into a port that is on a different controller. Still my UPS went offline the same as the screenshots I posted previously and then my UNRAID USB boot drive went offline too. After rebooting the whole server everything came back. Today I checked again and my UPS is undetected again.

 

I just removed NUT altogether and turned the built in UNRAID UPS service on and rebooted the whole server. So far so good but I will monitor for a while and see if I have the same problems with USB device disconnections without NUT installed.

Link to comment
35 minutes ago, Malakai said:

I moved all my USB devices to different ports. I made sure to plug the UPS into a port that is on a different controller. Still my UPS went offline the same as the screenshots I posted previously and then my UNRAID USB boot drive went offline too. After rebooting the whole server everything came back. Today I checked again and my UPS is undetected again.

 

I just removed NUT altogether and turned the built in UNRAID UPS service on and rebooted the whole server. So far so good but I will monitor for a while and see if I have the same problems with USB device disconnections without NUT installed.

 

If your UNRAID USB boot drive also goes offline, this is definitely not a NUT problem.

Link to comment

@Rysz I see that NUT 2.8.1 was just released but can you please make also the old version available? I experience random drop outs with the new version when the plugin checks for updates:

Nov  7 04:00:12 chipsServer upsmon[5656]: Signal 15: exiting
Nov  7 04:00:12 chipsServer upsd[5652]: User [email protected] logged out from UPS [ups]
Nov  7 04:00:12 chipsServer upsmon[5655]: upsmon parent: read
Nov  7 04:00:12 chipsServer upsd[5652]: mainloop: Interrupted system call
Nov  7 04:00:12 chipsServer upsd[5652]: Signal 15: exiting
Nov  7 04:00:12 chipsServer usbhid-ups[5648]: WARNING: send_to_all: write 34 bytes to socket 6 failed (ret=-1), disconnecting: Broken pipe
Nov  7 04:00:14 chipsServer usbhid-ups[5648]: Signal 15: exiting

 

Please not that I'm using the libssl3 version.

Link to comment
22 minutes ago, ich777 said:

@Rysz I see that NUT 2.8.1 was just released but can you please make also the old version available? I experience random drop outs with the new version when the plugin checks for updates:

Nov  7 04:00:12 chipsServer upsmon[5656]: Signal 15: exiting
Nov  7 04:00:12 chipsServer upsd[5652]: User [email protected] logged out from UPS [ups]
Nov  7 04:00:12 chipsServer upsmon[5655]: upsmon parent: read
Nov  7 04:00:12 chipsServer upsd[5652]: mainloop: Interrupted system call
Nov  7 04:00:12 chipsServer upsd[5652]: Signal 15: exiting
Nov  7 04:00:12 chipsServer usbhid-ups[5648]: WARNING: send_to_all: write 34 bytes to socket 6 failed (ret=-1), disconnecting: Broken pipe
Nov  7 04:00:14 chipsServer usbhid-ups[5648]: Signal 15: exiting

 

Please not that I'm using the libssl3 version.

 

This doesn't really look like a NUT problem but rather something on your OS (e.g. another plugin or the OS itself if you're on some custom built/pre-release version since you're already using libssl3) sending a SIGTERM (= Signal 15) to the NUT services at 4am (note that the plugin itself doesn't run any periodic update checks).

 

So you'd need a 2.8.0 libssl3 version for 6.13+? I doubt it'll change much though, as all the log messages seem to be caused by the SIGTERM received... feel free to test it with this package though:

 

https://github.com/desertwitch/NUT-unRAID/blob/master/packages/nut-2.8.0-x86_64-1stable.ssl31.txz

 

And please let me know if you figured out what caused this for you!

 

For all other users (on versions 6.10 up to unreleased 6.13) there's the older backends available:

  • release (2.8.0 stable)
  • legacy (2.7.4 stable)

through the Network UPS Tools Backend Switch as usual. 🙂

 

Edited by Rysz
  • Thanks 1
Link to comment
18 minutes ago, Rysz said:

the NUT services at 4am (note that the plugin itself doesn't run any periodic update checks).

Yes, sorry forgot to include the lines before, this is actually CA Update which shows what is happening:

Nov  7 04:00:01 chipsServer Plugin Auto Update: Checking for available plugin updates
Nov  7 04:00:07 chipsServer Plugin Auto Update: Auto Updating nut-dw.plg
Nov  7 04:00:08 chipsServer plugin-manager: running: 'anonymous'
Nov  7 04:00:12 chipsServer upsmon[5656]: Signal 15: exiting

So I think the NUT plugin installation/update routine checks if NUT is running and ends it now before updating correct?

 

18 minutes ago, Rysz said:

So you'd need a 2.8.0 libssl3 version for 6.13+?

It would be nice if you could release a version for libssl1 too.

 

BTW, would you be okay if I issue a PR where users can hide "Pipe error" from their syslog with a setting in the plugin (which is by default disabled) :

grafik.png.39083c7db9c2bf5e47a5e5a50ebbbaec.png

Link to comment
15 minutes ago, ich777 said:

Yes, sorry forgot to include the lines before, this is actually CA Update which shows what is happening:

Nov  7 04:00:01 chipsServer Plugin Auto Update: Checking for available plugin updates
Nov  7 04:00:07 chipsServer Plugin Auto Update: Auto Updating nut-dw.plg
Nov  7 04:00:08 chipsServer plugin-manager: running: 'anonymous'
Nov  7 04:00:12 chipsServer upsmon[5656]: Signal 15: exiting

So I think the NUT plugin installation/update routine checks if NUT is running and ends it now before updating correct?

 

It would be nice if you could release a version for libssl1 too.

 

BTW, would you be okay if I issue a PR where users can hide "Pipe error" from their syslog with a setting in the plugin:

grafik.png.39083c7db9c2bf5e47a5e5a50ebbbaec.png

 

OK that makes more sense in this context, it seems it's doing an actual unsupervised update/"auto update" to the plugin and not just checking if there's an update available.

 

As part of the updating process NUT services are always stopped (so there are no file locks during updating). So that itself would explain the SIGTERM but after the update the services should be brought up again through the following lines:

echo "Starting NUT services..."
/etc/rc.d/rc.nut start

 

Is there anything in the logs that would indicate it attempted or failed to bring up the services again? Maybe this is a permission issue that 'anonymous' (as in your log) is not able or allowed to bring up the services as opposed to a "manual update"?

 

There are already libssl1 versions of older backends (namely release 2.8.0 / legacy 2.7.4) available and they should be visible on the Network UPS Tools Backend Switch. That is unless you're on a version that's not between 6.10 and 6.12.99, so on 6.13 you'd only see "default" - because I had no access to such a version yet and hence wasn't able to test anything like that. 🙂

 

P.S. Feel free to submit a PR, but I'll have to think about it and can't promise I'll eventually merge it. I'm always relatively conservative on the decision what's useless noise and what's useful diagnostic information to others (or the backend developers when issues are brought up through GitHub). NUT is a relatively talkative program by design as the backend developers also seem to share this approach. Alternatively one can, of course, always also set up their syslog services to filter or discard useless information.

 

Edited by Rysz
Link to comment

Hi.


I am brand new to NUTS and Unraid, but my Unraid server is up and running with most of what I need running on it, so it was time to get the UPS up and running.

 

I have Powerwalker VI 1200 up and running.

 

A week ago I installed NUTS, and got it up and running straight off the bat. But a few days ago it had stopped which I noticed since the Page Footer was no longer showing.

 

I get the following message when trying to start it:

NUT was not able to start successfully - please check the SYSLOG for more information.

 

Log file says:

Nov  7 02:08:02 Tower kernel: PMS LoudnessCmd[21473]: segfault at 0 ip 0000147258511080 sp 000014725394a0c8 error 4 in libswresample.so.4[147258509000+18000] likely on CPU 2 (core 2, socket 0)
Nov  7 02:08:02 Tower kernel: Code: 01 cf 4c 39 c7 72 e3 c3 cc cc 8d 04 49 48 98 4d 89 c1 49 29 c1 48 63 c2 48 63 c9 49 39 f9 76 75 f2 0f 10 05 02 05 ff ff 66 90 <0f> bf 16 0f 57 c9 f2 0f 2a ca f2 0f 59 c8 f2 0f 11 0f 0f bf 14 06
Nov  7 02:08:04 Tower root: Updating permissions for NUT...
Nov  7 02:08:04 Tower root: Checking if the NUT Runtime Statistics Module should be enabled...
Nov  7 02:08:04 Tower root: Disabling the NUT Runtime Statistics Module...
Nov  7 02:08:05 Tower flash_backup: adding task: /usr/local/emhttp/plugins/dynamix.my.servers/scripts/UpdateFlashBackup update
Nov  7 02:08:05 Tower root: Network UPS Tools - Generic HID driver 0.52 (2.8.1)
Nov  7 02:08:05 Tower root: USB communication driver (libusb 1.0) 0.46
Nov  7 02:08:05 Tower root: libusb1: Could not open any HID devices: insufficient permissions on everything
Nov  7 02:08:05 Tower root: No matching HID UPS found
Nov  7 02:08:05 Tower root: Driver failed to start (exit status=1)
Nov  7 02:08:05 Tower root: Network UPS Tools - UPS driver controller 2.8.1
Nov  7 02:09:05 Tower flash_backup: adding task: /usr/local/emhttp/plugins/dynamix.my.servers/scripts/UpdateFlashBackup update

 

I tried running the Auto Config and it produced the following information:

[nutdev1]
driver = "usbhid-ups"
port = "auto"
vendorid = "06DA"
productid = "FFFF"
bus = "001"
device = "017"
busport = "003"
###NOTMATCHED-YET###bcdDevice = "0003"
 

I did nothing to the setup myselves after it worked until it stopped, but the setup I am messing with now looks like this:

image.png.cb4d8008129ec9e38a169c42f47818d9.png

 

Any help would be greatly appreciated.

 

PS: Where is the configfile for NUT located?

Link to comment
4 minutes ago, Rysz said:

it seems it's doing an actual unsupervised update/"auto update" to the plugin and not just checking if there's an update available.

The process should be the same is if you do that from the GUI:

Go to the Plugin page

Search for Updates

Update the Plugin manually

 

6 minutes ago, Rysz said:

Maybe this is a permission issue that 'anonymous' (as in your log) is not able or allowed to bring up the services as opposed to a "manual update"?

This is just a the default output from CA Update and means that it is running as root.

 

6 minutes ago, Rysz said:

Is there anything in the logs that would indicate it attempted or failed to bring up the services again?

Sadly enough no, the lines that I posted (spread through the two posts) are all that I got.

Link to comment
6 minutes ago, tormi said:

Hi.


I am brand new to NUTS and Unraid, but my Unraid server is up and running with most of what I need running on it, so it was time to get the UPS up and running.

 

I have Powerwalker VI 1200 up and running.

 

A week ago I installed NUTS, and got it up and running straight off the bat. But a few days ago it had stopped which I noticed since the Page Footer was no longer showing.

 

I get the following message when trying to start it:

NUT was not able to start successfully - please check the SYSLOG for more information.

 

Log file says:

Nov  7 02:08:02 Tower kernel: PMS LoudnessCmd[21473]: segfault at 0 ip 0000147258511080 sp 000014725394a0c8 error 4 in libswresample.so.4[147258509000+18000] likely on CPU 2 (core 2, socket 0)
Nov  7 02:08:02 Tower kernel: Code: 01 cf 4c 39 c7 72 e3 c3 cc cc 8d 04 49 48 98 4d 89 c1 49 29 c1 48 63 c2 48 63 c9 49 39 f9 76 75 f2 0f 10 05 02 05 ff ff 66 90 <0f> bf 16 0f 57 c9 f2 0f 2a ca f2 0f 59 c8 f2 0f 11 0f 0f bf 14 06
Nov  7 02:08:04 Tower root: Updating permissions for NUT...
Nov  7 02:08:04 Tower root: Checking if the NUT Runtime Statistics Module should be enabled...
Nov  7 02:08:04 Tower root: Disabling the NUT Runtime Statistics Module...
Nov  7 02:08:05 Tower flash_backup: adding task: /usr/local/emhttp/plugins/dynamix.my.servers/scripts/UpdateFlashBackup update
Nov  7 02:08:05 Tower root: Network UPS Tools - Generic HID driver 0.52 (2.8.1)
Nov  7 02:08:05 Tower root: USB communication driver (libusb 1.0) 0.46
Nov  7 02:08:05 Tower root: libusb1: Could not open any HID devices: insufficient permissions on everything
Nov  7 02:08:05 Tower root: No matching HID UPS found
Nov  7 02:08:05 Tower root: Driver failed to start (exit status=1)
Nov  7 02:08:05 Tower root: Network UPS Tools - UPS driver controller 2.8.1
Nov  7 02:09:05 Tower flash_backup: adding task: /usr/local/emhttp/plugins/dynamix.my.servers/scripts/UpdateFlashBackup update

 

I tried running the Auto Config and it produced the following information:

[nutdev1]
driver = "usbhid-ups"
port = "auto"
vendorid = "06DA"
productid = "FFFF"
bus = "001"
device = "017"
busport = "003"
###NOTMATCHED-YET###bcdDevice = "0003"
 

I did nothing to the setup myselves after it worked until it stopped, but the setup I am messing with now looks like this:

image.png.cb4d8008129ec9e38a169c42f47818d9.png

 

Any help would be greatly appreciated.

 

PS: Where is the configfile for NUT located?

 

I would suggest to "Reset Config" and then set it up again as in your screenshot.

Maybe there are some broken parts in your configuration that's causing the issue.

 

You can see the configuration files at the end of the "NUT Settings" page.

 

Edited by Rysz
Link to comment
4 minutes ago, ich777 said:

The process should be the same is if you do that from the GUI:

Go to the Plugin page

Search for Updates

Update the Plugin manually

 

This is just a the default output from CA Update and means that it is running as root.

 

Sadly enough no, the lines that I posted (spread through the two posts) are all that I got.

 

Just ran it with a manual update and it started them back up just fine:

Nov  7 12:12:24 Tower upsmon[2098]: Signal 15: exiting
Nov  7 12:12:24 Tower upsd[2094]: User [email protected] logged out from UPS [ups]
Nov  7 12:12:24 Tower upsmon[2097]: upsmon parent: read
Nov  7 12:12:24 Tower upsd[2094]: mainloop: Interrupted system call
Nov  7 12:12:24 Tower upsd[2094]: Signal 15: exiting
Nov  7 12:12:25 Tower dummy-ups[2090]: WARNING: send_to_all: write 29 bytes to socket 8 failed (ret=-1), disconnecting: Broken pipe
Nov  7 12:12:28 Tower dummy-ups[2090]: Signal 15: exiting
Nov  7 12:12:28 Tower root: plugin: checking: /boot/config/plugins/nut/nut-2.8.0-x86_64-12master.ssl11.txz - MD5
Nov  7 12:12:28 Tower root: plugin: skipping: /boot/config/plugins/nut/nut-2.8.0-x86_64-12master.ssl11.txz already exists
Nov  7 12:12:28 Tower root: plugin: checking: /boot/config/plugins/nut/nut-2.8.1-x86_64-2stable.ssl11.txz - MD5
Nov  7 12:12:28 Tower root: plugin: skipping: /boot/config/plugins/nut/nut-2.8.1-x86_64-2stable.ssl11.txz already exists
Nov  7 12:12:28 Tower root: plugin: checking: /boot/config/plugins/nut/nut-2.8.0-x86_64-1stable.ssl11.txz - MD5
Nov  7 12:12:28 Tower root: plugin: skipping: /boot/config/plugins/nut/nut-2.8.0-x86_64-1stable.ssl11.txz already exists
Nov  7 12:12:28 Tower root: plugin: checking: /boot/config/plugins/nut/nut-2.7.4.20200318-x86_64-1.txz - MD5
Nov  7 12:12:28 Tower root: plugin: skipping: /boot/config/plugins/nut/nut-2.7.4.20200318-x86_64-1.txz already exists
Nov  7 12:12:28 Tower root: plugin: running: anonymous
Nov  7 12:12:28 Tower root: plugin: checking: /boot/config/plugins/nut/net-snmp-5.9.3-x86_64-1.txz - MD5
Nov  7 12:12:28 Tower root: plugin: skipping: /boot/config/plugins/nut/net-snmp-5.9.3-x86_64-1.txz already exists
Nov  7 12:12:28 Tower root: plugin: running: upgradepkg --install-new /boot/config/plugins/nut/net-snmp-5.9.3-x86_64-1.txz
Nov  7 12:12:28 Tower root: plugin: checking: /boot/config/plugins/nut/libmodbus-3.1.10-x86_64-1usb.txz - MD5
Nov  7 12:12:28 Tower root: plugin: skipping: /boot/config/plugins/nut/libmodbus-3.1.10-x86_64-1usb.txz already exists
Nov  7 12:12:28 Tower root: plugin: running: upgradepkg --install-new /boot/config/plugins/nut/libmodbus-3.1.10-x86_64-1usb.txz
Nov  7 12:12:28 Tower root: plugin: checking: /boot/config/plugins/nut/nut-plugin-2023.11.06-x86_64-1.txz - MD5
Nov  7 12:12:28 Tower root: plugin: skipping: /boot/config/plugins/nut/nut-plugin-2023.11.06-x86_64-1.txz already exists
Nov  7 12:12:28 Tower root: plugin: running: upgradepkg --install-new /boot/config/plugins/nut/nut-plugin-2023.11.06-x86_64-1.txz
Nov  7 12:12:28 Tower root: plugin: running: anonymous
Nov  7 12:12:33 Tower dummy-ups[9170]: Startup successful
Nov  7 12:12:34 Tower upsd[9183]: listening on 0.0.0.0 port 3493
Nov  7 12:12:34 Tower upsd[9183]: Connected to UPS [ups]: dummy-ups-ups
Nov  7 12:12:34 Tower dummy-ups[9170]: sock_connect: enabling asynchronous mode (auto)
Nov  7 12:12:34 Tower upsd[9183]: Found 1 UPS defined in ups.conf
Nov  7 12:12:34 Tower upsd[9184]: Startup successful
Nov  7 12:12:34 Tower upsmon[9187]: Startup successful
Nov  7 12:12:34 Tower upsd[9184]: User [email protected] logged into UPS [ups]
Nov  7 12:12:34 Tower root: plugin: nut-dw.plg updated

 

So you'll see the same SIGTERM but then the processes get started up again just fine...

I'll test this some more with the auto update and will report back as soon as I know more 🙂

 

  • Thanks 1
Link to comment
3 minutes ago, Rysz said:

 

I would suggest to "Reset Config" and then set it up again as in your screenshot.

Maybe there are some broken parts in your configuration that's causing the issue.

 

You can see the configuration files at the end of the "NUT Settings" page.

 

 

Thanks for suggestion. Reset and reboot did nothing.

 

I have not added anything to the config file, neither did I do this when I got it working on the first try. (Should something be added here?

 

Logfile does not have as many errors now, but Driver fails to start.

Nov  7 03:10:46 Tower emhttpd: cmd: /usr/local/emhttp/plugins/nut/scripts/resetconf
Nov  7 03:11:08 Tower flash_backup: adding task: /usr/local/emhttp/plugins/dynamix.my.servers/scripts/UpdateFlashBackup update
Nov  7 03:12:30 Tower ool www[19156]: /usr/local/emhttp/plugins/nut/scripts/start
Nov  7 03:12:31 Tower root: Writing NUT configuration...
Nov  7 03:12:50 Tower root: Updating permissions for NUT...
Nov  7 03:12:50 Tower root: Checking if the NUT Runtime Statistics Module should be enabled...
Nov  7 03:12:50 Tower root: Disabling the NUT Runtime Statistics Module...
Nov  7 03:12:51 Tower root: Network UPS Tools - Generic HID driver 0.52 (2.8.1)
Nov  7 03:12:51 Tower root: USB communication driver (libusb 1.0) 0.46
Nov  7 03:12:51 Tower root: libusb1: Could not open any HID devices: insufficient permissions on everything
Nov  7 03:12:51 Tower root: No matching HID UPS found
Nov  7 03:12:51 Tower root: Driver failed to start (exit status=1)
Nov  7 03:12:51 Tower root: Network UPS Tools - UPS driver controller 2.8.1
Nov  7 03:13:18 Tower flash_backup: adding task: /usr/local/emhttp/plugins/dynamix.my.servers/scripts/UpdateFlashBackup update

 

Link to comment
Just now, tormi said:

 

Thanks for suggestion. Reset and reboot did nothing.

 

I have not added anything to the config file, neither did I do this when I got it working on the first try. (Should something be added here?

 

Logfile does not have as many errors now, but Driver fails to start.

Nov  7 03:10:46 Tower emhttpd: cmd: /usr/local/emhttp/plugins/nut/scripts/resetconf
Nov  7 03:11:08 Tower flash_backup: adding task: /usr/local/emhttp/plugins/dynamix.my.servers/scripts/UpdateFlashBackup update
Nov  7 03:12:30 Tower ool www[19156]: /usr/local/emhttp/plugins/nut/scripts/start
Nov  7 03:12:31 Tower root: Writing NUT configuration...
Nov  7 03:12:50 Tower root: Updating permissions for NUT...
Nov  7 03:12:50 Tower root: Checking if the NUT Runtime Statistics Module should be enabled...
Nov  7 03:12:50 Tower root: Disabling the NUT Runtime Statistics Module...
Nov  7 03:12:51 Tower root: Network UPS Tools - Generic HID driver 0.52 (2.8.1)
Nov  7 03:12:51 Tower root: USB communication driver (libusb 1.0) 0.46
Nov  7 03:12:51 Tower root: libusb1: Could not open any HID devices: insufficient permissions on everything
Nov  7 03:12:51 Tower root: No matching HID UPS found
Nov  7 03:12:51 Tower root: Driver failed to start (exit status=1)
Nov  7 03:12:51 Tower root: Network UPS Tools - UPS driver controller 2.8.1
Nov  7 03:13:18 Tower flash_backup: adding task: /usr/local/emhttp/plugins/dynamix.my.servers/scripts/UpdateFlashBackup update

 

 

Did you also try "Reset Config" and then afterwards "Auto Config" again?

If possible can you send me a PM with your debug package after "Auto Config" - it's on "NUT Settings" page:

grafik.png.3a9584637118165cff0fd63737e269aa.png

  • Like 1
Link to comment

@ich777: So I just tested it with "Auto Update" (thanks for telling me where to find it 😄 )

 

Nov  7 12:26:01 Tower Plugin Auto Update: Checking for available plugin updates
Nov  7 12:26:12 Tower Plugin Auto Update: Auto Updating nut-dw.plg
Nov  7 12:26:21 Tower root: plugin: running: anonymous
Nov  7 12:26:25 Tower upsmon[9189]: Signal 15: exiting
Nov  7 12:26:25 Tower upsd[9184]: User [email protected] logged out from UPS [ups]
Nov  7 12:26:25 Tower upsmon[9187]: upsmon parent: read
Nov  7 12:26:25 Tower upsd[9184]: mainloop: Interrupted system call
Nov  7 12:26:25 Tower upsd[9184]: Signal 15: exiting
Nov  7 12:26:25 Tower dummy-ups[9170]: WARNING: send_to_all: write 34 bytes to socket 13 failed (ret=-1), disconnecting: Broken pipe
Nov  7 12:26:27 Tower dummy-ups[9170]: Signal 15: exiting
Nov  7 12:26:28 Tower root: plugin: checking: /boot/config/plugins/nut/nut-2.8.0-x86_64-12master.ssl11.txz - MD5
Nov  7 12:26:28 Tower root: plugin: skipping: /boot/config/plugins/nut/nut-2.8.0-x86_64-12master.ssl11.txz already exists
Nov  7 12:26:28 Tower root: plugin: checking: /boot/config/plugins/nut/nut-2.8.1-x86_64-2stable.ssl11.txz - MD5
Nov  7 12:26:28 Tower root: plugin: skipping: /boot/config/plugins/nut/nut-2.8.1-x86_64-2stable.ssl11.txz already exists
Nov  7 12:26:28 Tower root: plugin: checking: /boot/config/plugins/nut/nut-2.8.0-x86_64-1stable.ssl11.txz - MD5
Nov  7 12:26:28 Tower root: plugin: skipping: /boot/config/plugins/nut/nut-2.8.0-x86_64-1stable.ssl11.txz already exists
Nov  7 12:26:28 Tower root: plugin: checking: /boot/config/plugins/nut/nut-2.7.4.20200318-x86_64-1.txz - MD5
Nov  7 12:26:28 Tower root: plugin: skipping: /boot/config/plugins/nut/nut-2.7.4.20200318-x86_64-1.txz already exists
Nov  7 12:26:28 Tower root: plugin: running: anonymous
Nov  7 12:26:28 Tower root: plugin: checking: /boot/config/plugins/nut/net-snmp-5.9.3-x86_64-1.txz - MD5
Nov  7 12:26:28 Tower root: plugin: skipping: /boot/config/plugins/nut/net-snmp-5.9.3-x86_64-1.txz already exists
Nov  7 12:26:28 Tower root: plugin: running: upgradepkg --install-new /boot/config/plugins/nut/net-snmp-5.9.3-x86_64-1.txz
Nov  7 12:26:28 Tower root: plugin: checking: /boot/config/plugins/nut/libmodbus-3.1.10-x86_64-1usb.txz - MD5
Nov  7 12:26:28 Tower root: plugin: skipping: /boot/config/plugins/nut/libmodbus-3.1.10-x86_64-1usb.txz already exists
Nov  7 12:26:28 Tower root: plugin: running: upgradepkg --install-new /boot/config/plugins/nut/libmodbus-3.1.10-x86_64-1usb.txz
Nov  7 12:26:28 Tower root: plugin: checking: /boot/config/plugins/nut/nut-plugin-2023.11.06-x86_64-1.txz - MD5
Nov  7 12:26:28 Tower root: plugin: skipping: /boot/config/plugins/nut/nut-plugin-2023.11.06-x86_64-1.txz already exists
Nov  7 12:26:28 Tower root: plugin: running: upgradepkg --install-new /boot/config/plugins/nut/nut-plugin-2023.11.06-x86_64-1.txz
Nov  7 12:26:28 Tower root: plugin: running: anonymous
Nov  7 12:26:33 Tower dummy-ups[18158]: Startup successful
Nov  7 12:26:34 Tower upsd[18168]: listening on 0.0.0.0 port 3493
Nov  7 12:26:34 Tower upsd[18168]: Connected to UPS [ups]: dummy-ups-ups
Nov  7 12:26:34 Tower dummy-ups[18158]: sock_connect: enabling asynchronous mode (auto)
Nov  7 12:26:34 Tower upsd[18168]: Found 1 UPS defined in ups.conf
Nov  7 12:26:34 Tower upsd[18169]: Startup successful
Nov  7 12:26:34 Tower upsmon[18172]: Startup successful
Nov  7 12:26:34 Tower upsd[18169]: User [email protected] logged into UPS [ups]
Nov  7 12:26:34 Tower root: plugin: nut-dw.plg updated

 

Can't reproduce the problem here, seems to work as it should on NUT 2.8.1 even with "Auto Update". But I'll monitor this over the next few days and will also investigate it some more when pre-release/release candidate versions of 6.13 become available, I currently have no way to test those libssl3 versions apart from my Slackware 15.1 build environment where they work just fine.

 

In general though I'd advise against auto-updating NUT because if problems (such as this one) occur during updating, they're more likely to be noticed only much later. Worst case the services don't come up as they should like here and a power failure occurs in that time-frame between the problem and the user noticing there's something wrong.

  • Thanks 1
Link to comment

Just to mention. I have the exact same model as @tormi, the PowerWalker VI 1200. Got the same error as well. A reset didn't help either.

 

Nov  9 11:52:24 xsserver emhttpd: cmd: /usr/local/emhttp/plugins/nut/scripts/resetconf
Nov  9 11:53:36 xsserver ool www[22984]: /usr/local/emhttp/plugins/nut/scripts/clear_stats
Nov  9 11:53:37 xsserver root: Disabling the NUT Runtime Statistics Module...
Nov  9 11:53:38 xsserver root: Writing NUT configuration...
Nov  9 11:53:39 xsserver root: Updating permissions for NUT...
Nov  9 11:53:39 xsserver root: Checking if the NUT Runtime Statistics Module should be enabled...
Nov  9 11:53:39 xsserver root: Enabling the NUT Runtime Statistics Module...
Nov  9 11:53:41 xsserver root: NUT Runtime Statistics is requesting the first batch of data...
Nov  9 11:53:41 xsserver root: NUTSTATS: NUT Service is disabled... exiting
Nov  9 11:54:26 xsserver ool www[22984]: /usr/local/emhttp/plugins/nut/scripts/start
Nov  9 11:54:27 xsserver root: Writing NUT configuration...
Nov  9 11:54:29 xsserver root: Updating permissions for NUT...
Nov  9 11:54:29 xsserver root: Checking if the NUT Runtime Statistics Module should be enabled...
Nov  9 11:54:29 xsserver root: Enabling the NUT Runtime Statistics Module...
Nov  9 11:54:30 xsserver root: Network UPS Tools - Generic HID driver 0.52 (2.8.1)
Nov  9 11:54:30 xsserver root: USB communication driver (libusb 1.0) 0.46
Nov  9 11:54:30 xsserver root: libusb1: Could not open any HID devices: insufficient permissions on everything
Nov  9 11:54:30 xsserver root: No matching HID UPS found
Nov  9 11:54:30 xsserver root: Driver failed to start (exit status=1)
Nov  9 11:54:30 xsserver root: Network UPS Tools - UPS driver controller 2.8.1

 

Link to comment

Sorry there's not really much I can do about individual UPS device's compatibility with NUT. The limiting factor here are always the UPS drivers in the NUT backend, which is developed by other people and mostly with other operating systems in mind. Some UPS devices do work better with some older NUT backends, which you can choose using the Network UPS Tools Backend Switch. Apart from that all I can do here is help make sure that your NUT configuration is correct, which it seems to be in the above cases.

 

Here's some more information for your device:

https://networkupstools.org/ddl/PowerWalker/VI_1200_SH.html

It seems to have worked with 2.7.4. at some point, so you could try with the legacy (2.7.4. stable) backend.

Link to comment
On 11/9/2023 at 12:45 PM, xsweb said:

Just to mention. I have the exact same model as @tormi, the PowerWalker VI 1200. Got the same error as well. A reset didn't help either.

 

 

Hi @xsweb.

Nice to have a fellow PowerWalker with me. I was just going to write to @Rysz right now because mine started up again by magic:

 

As it is fresh in my memory I will post excactly what I did.

 

1. Turned off the server (I still hadd NUTS installed, so this time I did not unistall it)

2. Change USB port (again)

3. Fired up Unraid, and tried to start NUTS to no avail.

  • At this point my NUTS settings was like on the picture EXCEPT that "Enable Manual Config" was set to "something like UPS Device" (I don't remember the excact wording and I will not shut it down to find out :)).

 image.png.b944614b41f3dfe0abb0db07de82903d.png

 

4. The next I did was: Reset Config

5. I forgot to do Auto Config :)

6. I still did not work.

7. The ONLY thing I changed then was "Enable Maual Configuration" to "NO".

 

And voila, it is working again. Lets hope it lasts this time. Give it a try and GOOD luck.

 

@Rysz If you want to take a look at my config now, it is available, just let me know.

Edited by tormi
  • Like 1
Link to comment
50 minutes ago, tormi said:

Hi @xsweb.

Nice to have a fellow PowerWalker with me. I was just going to write to @Rysz right now because mine started up again by magic:

 

As it is fresh in my memory I will post excactly what I did.

 

1. Turned off the server (I still hadd NUTS installed, so this time I did not unistall it)

2. Change USB port (again)

3. Fired up Unraid, and tried to start NUTS to no avail.

  • At this point my NUTS settings was like on the picture EXCEPT that "Enable Manual Config" was set to "something like UPS Device" (I don't remember the excact wording and I will not shut it down to find out :)).

 image.png.b944614b41f3dfe0abb0db07de82903d.png

 

4. The next I did was: Reset Config

5. I forgot to do Auto Config :)

6. I still did not work.

7. The ONLY thing I changed then was "Enable Maual Configuration" to "NO".

 

And voila, it is working again. Lets hope it lasts this time. Give it a try and GOOD luck.

 

@Rysz If you want to take a look at my config now, it is available, just let me know.

 

Thanks a lot for sending me the NUT debug packages with your respective configurations. I've just compared the two configurations and it seems the NUT Scanner (= "Auto Config") misdetected either your USB port's information or UPS device's information. As a consequence, particularly by writing that wrong information into the configuration file, the UPS driver then only tried connecting to a UPS with said wrong information (and not all other possible UPS combinations it otherwise knows).

 

That's unfortunately one of the pitfalls when using "Auto Config". It aids detection, but makes the UPS driver "blind" to any other UPS devices it would usually otherwise know. I'll have to put this as a warning message somewhere, for more tricky UPS devices or UPS detection scenarios like yours.

 

To further illustrate this, here we have the old ups.conf configuration (with "Auto Config"):

	driver = "usbhid-ups"
	port = "auto"
	vendorid = "06DA"
	productid = "FFFF"
	product = "Offline UPS"
	serial = "000000000"
	vendor = "PPC"
	bus = "001"
	device = "029"
	busport = "009"

 

And this is the working new ups.conf configuration (without "Auto Config"):

driver = usbhid-ups
port = auto

 

When all those vendorid, productid, bus, device, ... parameters are not given to the UPS driver it basically starts lock-picking all possible other combinations of any UPS devices it otherwise knows, instead of just trying that one UPS device that NUT Scanner (= "Auto Config") has given to it.

 

That seems to have been successful in your case, by not pinning the UPS driver onto a specific USB port or UPS device it managed to autodetect it somehow else straight away. But in other cases it would need exactly that information we've now dropped to detect the UPS in the first place - so it remains a double-edged sword.

 

So in your case please do not use "Auto Config" for that UPS (it doesn't seem to work well in this specific case) and best don't change any of the UPS Driver Settings anymore now that it works. It should then continue working even after a system reboot. 🙂

 

Users with similar troubles I would recommend to attempt "Reset Config" and then not use "Auto Config" straight away, but instead try their respective UPS Driver with UPS Port set to auto first.

 

Edited by Rysz
  • Like 1
  • Thanks 1
Link to comment
On 10/22/2023 at 10:21 AM, Rysz said:

 

Thanks for reporting back, this is indeed the battery self test, we've luckily been able to fix the APC shutdown issue in the "default (recent master)" backend also since your report. So you can stay on 2.8.0 stable if it works well for you or update NUT and switch back to "default (recent master)". 🙂

 

Thanks for the update, I’ve switched to the default recent master.  I’ll report back if there are any issues.

Link to comment

This morning I got the message "Warning communication lost with UPS".

 

I checked my NUT Settings and the UPS is listed as "On Line" with battery charge and NUT Details. But in the UPS settings it states "Lost communication". I already restarted both services and also switched USB ports without any change.

 

I do see a few warnings in the syslog like "Poll UPS failed - Data stale" or when I restart the NUT service I get "WARNING: send_to_all: write 34 bytes to socket 16 failed (ret=-1), disconnecting: Broken pipe" 

 

diagnostics are attached.

 

I have the CyberPower CP1500EPFCLCD for a year now which was running without any issues.

fribb-tower-diagnostics-20231119-0502.zip

Edited by Fribb
Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.