Re: nut UPS shutdown issue after nut upgrade 2.8.2 -> 2.8.4
On 3/28/26 8:07 AM, Łukasz Michalski wrote:
On 3/28/26 2:20 AM, David C Rankin wrote:
Mar 27 19:07:55 valkyrie nut-driver@valkyrie_ups[830]: You may want to set 'pollonly' flag on CPS devices
I would try this.
Mar 27 19:08:49 valkyrie nut-server[940]: Data for UPS [valkyrie_ups] is stale - check driver Mar 27 19:08:49 valkyrie upsd[940]: Data for UPS [valkyrie_ups] is stale - check driver Mar 27 19:08:52 valkyrie nut-monitor[954]: Poll UPS [valkyrie_ups@localhost] failed - Data stale
Because of this.
Regards, Łukasz
Thank you Lukasz, I'm a bit confused where it goes? It's an option to usbhid-ups according to man upbhid-ups(8), but where in the config setup does it go? The Arch wiki (https://wiki.archlinux.org/title/Network_UPS_Tools#CyberPower_UPS_keeps_disc...) talks about creating an override.conf, but it is unclear whether that goes with nut-driver@.service.d or nut-driver@valkyrie_ups.service.d? The systemd targets and service files are a bit of a spiderweb: /etc/systemd/system/nut-driver.target.wants └── nut-driver@valkyrie_ups.service -> /usr/lib/systemd/system/nut-driver@.service /etc/systemd/system/nut-driver@.service.d └── nut-driver-enumerator-generated-checksum.conf /etc/systemd/system/nut-driver@valkyrie_ups.service.d ├── nut-driver-enumerator-generated-checksum.conf ├── nut-driver-enumerator-generated-devicename.conf ├── nut-driver-enumerator-generated-doclink.conf └── nut-driver-enumerator-generated.conf /etc/systemd/system/nut.target.wants ├── nut-driver-enumerator.service -> /usr/lib/systemd/system/nut-driver-enumerator.service ├── nut-driver.target -> /usr/lib/systemd/system/nut-driver.target ├── nut-monitor.service -> /usr/lib/systemd/system/nut-monitor.service └── nut-server.service -> /usr/lib/systemd/system/nut-server.service All this just to start NUT? The wiki says nut-driver@.service, but then follows with the name nut-driver@cyberpower.service to create override.conf and it's unclear what the inserted @cyberpower is referring to (presumably that's the UPS name, e.g. valkyrie_ups for me), but then which unit directory gets modified, the one without @name or the one with @name? This commanded shutdown occurred again at 10:39 this morning. The driver claimed a power failure and then lost communication (there was no power failure, the other six UPS were fine, no events) So this looks like a single disconnect event, or perhaps a self-test and then communications are lost? Picking up from the driver restart yesterday, the journal shows the following: Mar 27 19:49:18 valkyrie nut-driver@valkyrie_ups[2775]: Network UPS Tools upsdrvctl - UPS driver controller 2.8.4 release Mar 27 19:49:18 valkyrie nut-driver@valkyrie_ups[2793]: Network UPS Tools 2.8.4 release - Generic HID driver 0.67 Mar 27 19:49:18 valkyrie nut-driver@valkyrie_ups[2793]: USB communication driver (libusb 1.0) 0.50 Mar 27 19:49:18 valkyrie nut-driver@valkyrie_ups[2793]: Using subdriver: CyberPower HID 0.84 Mar 27 19:49:18 valkyrie nut-driver@valkyrie_ups[2793]: Defaulting 'pollfreq' to 12 for CPS devices Mar 27 19:49:18 valkyrie nut-driver@valkyrie_ups[2793]: You may want to set 'pollonly' flag on CPS devices Mar 27 19:49:18 valkyrie nut-driver@valkyrie_ups[2793]: Listening on socket /var/lib/nut/usbhid-ups-valkyrie_ups Mar 27 19:49:19 valkyrie nut-server[2351]: Connected to UPS [valkyrie_ups]: usbhid-ups-valkyrie_ups Mar 27 19:49:19 valkyrie upsd[2351]: Connected to UPS [valkyrie_ups]: usbhid-ups-valkyrie_ups Mar 27 19:49:19 valkyrie nut-monitor[2703]: Communications with UPS valkyrie_ups@localhost established Mar 27 19:49:19 valkyrie nut-monitor[2703]: UPS valkyrie_ups@localhost: has at least one unclassified status token: [WAIT] Mar 27 19:49:24 valkyrie nut-monitor[2703]: UPS valkyrie_ups@localhost has no unclassified status tokens anymore Mar 28 10:39:59 valkyrie nut-monitor[2703]: UPS valkyrie_ups@localhost on battery Mar 28 10:39:59 valkyrie usbhid-ups[2797]: nut_libusb_get_interrupt: No such device (it may have been disconnected) Mar 28 10:40:18 valkyrie nut-server[2351]: Data for UPS [valkyrie_ups] is stale - check driver Mar 28 10:40:18 valkyrie upsd[2351]: Data for UPS [valkyrie_ups] is stale - check driver Mar 28 10:40:19 valkyrie nut-monitor[2703]: Poll UPS [valkyrie_ups@localhost] failed - Data stale Mar 28 10:40:19 valkyrie nut-monitor[2703]: Communications with UPS valkyrie_ups@localhost lost Mar 28 10:40:24 valkyrie nut-monitor[2703]: Poll UPS [valkyrie_ups@localhost] failed - Data stale Mar 28 10:40:29 valkyrie nut-monitor[2703]: Poll UPS [valkyrie_ups@localhost] failed - Data stale Mar 28 10:40:34 valkyrie nut-monitor[2703]: Poll UPS [valkyrie_ups@localhost] failed - Data stale Mar 28 10:40:34 valkyrie nut-monitor[2703]: Executing automatic power-fail shutdown Mar 28 10:40:34 valkyrie upsd[2351]: Client david@::1 set FSD on UPS [valkyrie_ups] Mar 28 10:40:34 valkyrie nut-server[2351]: Client david@::1 set FSD on UPS [valkyrie_ups] Mar 28 10:40:34 valkyrie nut-monitor[2703]: Auto logout and shutdown proceeding Mar 28 10:40:39 valkyrie systemd[1]: nut-monitor.service: Deactivated successfully. Mar 28 10:40:39 valkyrie systemd[1]: nut-monitor.service: Consumed 9.434s CPU time over 14h 54min 9.506s wall clock time, 4.2M memory peak. Mar 28 10:40:39 valkyrie nut-server[2351]: mainloop: Interrupted system call Mar 28 10:40:39 valkyrie nut-server[2351]: Signal 15: exiting Mar 28 10:40:39 valkyrie upsd[2351]: mainloop: Interrupted system call Mar 28 10:40:39 valkyrie upsd[2351]: Signal 15: exiting Mar 28 10:40:39 valkyrie systemd[1]: nut-server.service: Deactivated successfully. Mar 28 10:40:39 valkyrie systemd[1]: nut-server.service: Consumed 4.229s CPU time over 15h 1min 9.271s wall clock time, 4.4M memory peak. Mar 28 10:40:39 valkyrie nut-driver@valkyrie_ups[17695]: Network UPS Tools upsdrvctl - UPS driver controller 2.8.4 release Mar 28 10:40:44 valkyrie nut-driver@valkyrie_ups[17695]: Stopping /run/nut/usbhid-ups-valkyrie_ups.pid failed, retrying harder: Success Mar 28 10:40:44 valkyrie systemd[1]: nut-driver@valkyrie_ups.service: Main process exited, code=killed, status=9/KILL Mar 28 10:40:45 valkyrie systemd[1]: nut-driver@valkyrie_ups.service: Failed with result 'signal'. Mar 28 10:40:45 valkyrie systemd[1]: nut-driver@valkyrie_ups.service: Consumed 11.833s CPU time over 14h 51min 27.223s wall clock time, 4.1M memory peak. The salient part starts with a spurious on-battery message and then the connection with the UPS fails. I'm beginning to wonder if the "on-battery" may not just be the daily self-test of the UPS, but then why does it stop communicating with nut-monitor? It ran for 5+ years with NUT 2.7 version and never had a disconnect issue, not one. Really strange. On restart after the shutdown this morning, the driver came up and connected just fine, so I'm not sure what to make of the issue. I'll mess with this a little more to see if I can get it to be stable, if not I'm just going to swap another APC 1500W UPS in and see if NUT will work with it, if not I'll just go with apcupsd. Thank you for your help! -- David C. Rankin, J.D.,P.E.
On 3/28/26 9:30 PM, David C Rankin wrote:
Thank you Lukasz,
I'm a bit confused where it goes? It's an option to usbhid-ups according to man upbhid-ups(8), but where in the config setup does it go? The Arch wiki (https://wiki.archlinux.org/title/Network_UPS_Tools#CyberPower_UPS_keeps_disc...) talks about creating an override.conf, but it is unclear whether that goes with nut-driver@.service.d or nut-driver@valkyrie_ups.service.d? The systemd targets and service files are a bit of a spiderweb:
I think that it is safer to alter nut-driver@valkyrie_ups.service. It is autogenerated by enumerator from /etc/nut/ups.conf entries. As for pollonly flag, it is an usbhid-ups config flag, so you have to add it to your ups section in /etc/nut/ups.conf.
Picking up from the driver restart yesterday, the journal shows the following:
The salient part starts with a spurious on-battery message and then the connection with the UPS fails. I'm beginning to wonder if the "on-battery" may not just be the daily self-test of the UPS, but then why does it stop communicating with nut-monitor? It ran for 5+ years with NUT 2.7 version and never had a disconnect issue, not one. Really strange.
It looks like regression. Maybe some defaults for |pollfreq | or |pollinterval |changed? Regards, Łukasz
On 3/28/26 4:58 PM, Łukasz Michalski wrote:
I think that it is safer to alter nut-driver@valkyrie_ups.service. It is autogenerated by enumerator from /etc/nut/ups.conf entries.
As for pollonly flag, it is an usbhid-ups config flag, so you have to add it to your ups section in /etc/nut/ups.conf.
Thank you will give this a shot if another comm loss and force shutdown occurs. I found the proper syntax that I was scratching my head about. Since it's a single flag, it's = enabled, e.g. pollonly = enabled in my [upsname] section of ups.conf. -- David C. Rankin, J.D.,P.E.
participants (2)
-
David C Rankin
-
Łukasz Michalski