Update 2.7.4 to 2.8.4 CP UPS driver disconnect (nut_libusb_get_report: No such device)

[drankinatty]

OS:   Archlinux
NUT:  nut 2.8.4-3

A few days ago, I updated an Arch server from NUT 2.7.4 to 2.8.4. The CP1350PFCLCD had been running for 8-9 years without a single driver disconnect, not one.

Upon update to 2.8.4 and moving config from /etc/ups to /etc/nut and making the various "master/slave" changes to "primary", 2.8.4 started and recognized the driver without issue. However, overnight, NUT lost contact with the UPS and then forced a commanded shutdown as a result. That's shouldn't have happened and something I've never experienced before. On the next kernel update/reboot, the driver established communication and was happy for several hours, before disconnecting again. Something is not right.

The UPS had roughly 1/2 life (30 min. of runtime on batteries before shutdown), so I decided to swap the UPS for a CP1350AVRLCDa with new batteries and full runtime (about an hour). I had also added the suggested "pollonly" option to the ups.conf within the driver section to possibly help with CyberPower disconnect/reconnect race conditions (though I had not seen any such race of disconnect/reconnect -- my problems was disconnect, never reconnect):

maxretry = 3
[valkyrie_ups]
        driver = usbhid-ups
        port = auto
        desc = "Valkyrie CP1350PFCLCD UPS"
        pollonly = enabled

After the UPS swap and boot, the new UPS was online and communicating with no issue:

$ upsc valkyrie_ups
battery.charge: 100
battery.charge.low: 10
battery.charge.warning: 20
battery.mfr.date: CPS
battery.runtime: 3869
battery.runtime.low: 300
battery.status: 100%
battery.type: PbAcid
battery.voltage: 27.1
battery.voltage.nominal: 24
device.mfr: CPS
device.model: CP1350AVRLCDa
device.serial: CDNJN2000560
device.type: ups
driver.debug: 0
driver.flag.allow_killpower: 0
driver.name: usbhid-ups
driver.parameter.interrupt_pipe_no_events_tolerance: -1
driver.parameter.pollfreq: 12
driver.parameter.pollinterval: 2
driver.parameter.pollonly: enabled
driver.parameter.port: auto
driver.parameter.synchronous: auto
driver.state: quiet
driver.version: 2.8.4
driver.version.data: CyberPower HID 0.84
driver.version.internal: 0.67
driver.version.usb: libusb-1.0.29 (API: 0x0100010B)
input.sensitivity: normal
input.transfer.high: 139
input.transfer.low: 100
input.voltage: 121.0
input.voltage.nominal: 120
output.voltage: 121.0
ups.beeper.status: enabled
ups.delay.shutdown: 60
ups.delay.start: 120
ups.firmware: BF01511BA
ups.load: 11
ups.mfr: CPS
ups.model: CP1350AVRLCDa
ups.power: 95
ups.power.nominal: 1350
ups.productid: 0501
ups.realpower: 89
ups.realpower.nominal: 815
ups.serial: CDNJN2000560
ups.status: OL
ups.test.result: No test initiated
ups.timer.shutdown: -60
ups.timer.start: -60
ups.vendorid: 0764

All good I thought. This UPS had the same disconnect approximately 11 minutes later even though "pollonly" was set. The journal entries show the following from this last boot with the new UPS:

Mar 30 00:05:41 valkyrie systemd[1]: nut-udev-settle.service: Deactivated successfully.
Mar 30 00:05:47 valkyrie nut-driver@valkyrie_ups[749]: Network UPS Tools upsdrvctl - UPS driver controller 2.8.4 release
Mar 30 00:05:47 valkyrie nut-driver@valkyrie_ups[832]: Network UPS Tools 2.8.4 release - Generic HID driver 0.67
Mar 30 00:05:47 valkyrie nut-driver@valkyrie_ups[832]: USB communication driver (libusb 1.0) 0.50
Mar 30 00:05:47 valkyrie nut-driver@valkyrie_ups[832]: Using subdriver: CyberPower HID 0.84
Mar 30 00:05:47 valkyrie nut-driver-enumerator[748]: Keeping systemd service instance 'valkyrie_ups' whose section 'valkyrie_ups' in config file has changed: live reload sufficed. Saving updated info into service properties.
Mar 30 00:05:47 valkyrie nut-driver@valkyrie_ups[832]: Defaulting 'pollfreq' to 12 for CPS devices
Mar 30 00:05:47 valkyrie nut-driver@valkyrie_ups[832]: Listening on socket /var/lib/nut/usbhid-ups-valkyrie_ups
Mar 30 00:05:48 valkyrie nut-driver-enumerator[748]: OK
Mar 30 00:05:48 valkyrie systemd[1]: Reload requested from client PID 922 ('systemctl') (unit nut-driver-enumerator.service)...
Mar 30 00:05:48 valkyrie nut-driver-enumerator[748]: === The currently defined service instances are:
Mar 30 00:05:48 valkyrie nut-driver-enumerator[748]: valkyrie_ups
Mar 30 00:05:48 valkyrie nut-driver-enumerator[748]: === The currently defined configurations in '/etc/nut/ups.conf' are:
Mar 30 00:05:48 valkyrie nut-driver-enumerator[748]: valkyrie_ups
Mar 30 00:05:48 valkyrie nut-driver-enumerator[748]: Mon Mar 30 05:05:48 AM UTC 2026 : OK: No more changes to reconcile between systemd service instances and device configurations in '/etc/nut/ups.conf'
Mar 30 00:05:48 valkyrie systemd[1]: nut-driver-enumerator.service: Deactivated successfully.
Mar 30 00:05:51 valkyrie nut-server[1042]: Limit                     Soft Limit           Hard Limit           Units
Mar 30 00:05:51 valkyrie nut-server[1042]: Max open files            1048576              1048576              files
Mar 30 00:05:51 valkyrie nut-server[1041]: Network UPS Tools upsd 2.8.4 release
Mar 30 00:05:51 valkyrie nut-server[1041]: listening on ::1 port 3493
Mar 30 00:05:51 valkyrie nut-server[1041]: listening on 127.0.0.1 port 3493
Mar 30 00:05:51 valkyrie upsd[1041]: listening on ::1 port 3493
Mar 30 00:05:51 valkyrie upsd[1041]: listening on 127.0.0.1 port 3493
Mar 30 00:05:52 valkyrie nut-server[1041]: Connected to UPS [valkyrie_ups]: usbhid-ups-valkyrie_ups
Mar 30 00:05:52 valkyrie nut-server[1041]: Found 1 UPS defined in ups.conf
Mar 30 00:05:52 valkyrie upsd[1041]: Connected to UPS [valkyrie_ups]: usbhid-ups-valkyrie_ups
Mar 30 00:05:52 valkyrie upsd[1041]: Found 1 UPS defined in ups.conf
Mar 30 00:05:52 valkyrie nut-server[1041]: Running as foreground process, not saving a PID file
Mar 30 00:05:52 valkyrie nut-server[1041]: upsnotify: notify about state NOTIFY_STATE_READY_WITH_PID with libsystemd: was requested, but not running as a service unit now, will not spam more about it
Mar 30 00:05:52 valkyrie nut-server[1041]: upsnotify: failed to notify about state NOTIFY_STATE_READY_WITH_PID: no notification tech defined, will not spam more about it
Mar 30 00:05:52 valkyrie nut-server[1041]: upsnotify: logged the systemd watchdog situation once, will not spam more about it
Mar 30 00:05:52 valkyrie upsd[1041]: Running as foreground process, not saving a PID file
Mar 30 00:05:52 valkyrie upsd[1041]: upsnotify: notify about state NOTIFY_STATE_READY_WITH_PID with libsystemd: was requested, but not running as a service unit now, will not spam more about it
Mar 30 00:05:52 valkyrie upsd[1041]: upsnotify: failed to notify about state NOTIFY_STATE_READY_WITH_PID: no notification tech defined, will not spam more about it
Mar 30 00:05:52 valkyrie upsd[1041]: upsnotify: logged the systemd watchdog situation once, will not spam more about it
Mar 30 00:05:52 valkyrie nut-monitor[1058]: Network UPS Tools upsmon 2.8.4 release
Mar 30 00:05:52 valkyrie nut-monitor[1058]: UPS: valkyrie_ups@localhost (primary) (power value 1)
Mar 30 00:05:52 valkyrie nut-monitor[1058]: Using power down flag file /etc/killpower
Mar 30 00:05:52 valkyrie nut-monitor[1058]: Warning: no custom notification command defined, just so you know
Mar 30 00:05:52 valkyrie nut-monitor[1063]: upsnotify: notify about state NOTIFY_STATE_READY_WITH_PID with libsystemd: was requested, but not running as a service unit now, will not spam more about it
Mar 30 00:05:52 valkyrie nut-monitor[1063]: upsnotify: failed to notify about state NOTIFY_STATE_READY_WITH_PID: no notification tech defined, will not spam more about it
Mar 30 00:05:55 valkyrie nut-monitor[1063]: upsmon: initialized OS integration for sleep inhibitor
Mar 30 00:05:55 valkyrie nut-monitor[1063]: upsmon: initialized OS integration for sleep/wake monitoring
Mar 30 00:05:55 valkyrie nut-monitor[1063]: upsnotify: logged the systemd watchdog situation once, will not spam more about it
Mar 30 00:05:55 valkyrie nut-server[1041]: User david@::1 logged into UPS [valkyrie_ups]
Mar 30 00:05:55 valkyrie upsd[1041]: User david@::1 logged into UPS [valkyrie_ups]
Mar 30 02:16:55 valkyrie usbhid-ups[912]: nut_libusb_get_report: No such device (it may have been disconnected)
Mar 30 02:17:14 valkyrie nut-server[1041]: Data for UPS [valkyrie_ups] is stale - check driver
Mar 30 02:17:14 valkyrie upsd[1041]: Data for UPS [valkyrie_ups] is stale - check driver
Mar 30 02:17:15 valkyrie nut-monitor[1063]: Poll UPS [valkyrie_ups@localhost] failed - Data stale
Mar 30 02:17:15 valkyrie nut-monitor[1063]: Communications with UPS valkyrie_ups@localhost lost
Mar 30 02:17:20 valkyrie nut-monitor[1063]: Poll UPS [valkyrie_ups@localhost] failed - Data stale
Mar 30 02:17:25 valkyrie nut-monitor[1063]: Poll UPS [valkyrie_ups@localhost] failed - Data stale
Mar 30 02:17:30 valkyrie nut-monitor[1063]: Poll UPS [valkyrie_ups@localhost] failed - Data stale
Mar 30 02:17:35 valkyrie nut-monitor[1063]: Poll UPS [valkyrie_ups@localhost] failed - Data stale
Mar 30 02:17:40 valkyrie nut-monitor[1063]: Poll UPS [valkyrie_ups@localhost] failed - Data stale
<snip every 5 second spamming log that continues until the driver is restarted>
Mar 30 02:22:10 valkyrie nut-monitor[1063]: Poll UPS [valkyrie_ups@localhost] failed - Data stale
Mar 30 02:22:10 valkyrie nut-monitor[1063]: UPS valkyrie_ups@localhost is unavailable
Mar 30 02:22:15 valkyrie nut-monitor[1063]: Poll UPS [valkyrie_ups@localhost] failed - Data stale
<snip more 5 second spamming>
Mar 30 02:47:51 valkyrie nut-monitor[1063]: Poll UPS [valkyrie_ups@localhost] failed - Data stale
Mar 30 02:47:56 valkyrie nut-server[1041]: Send ping to UPS [valkyrie_ups] failed: Resource temporarily unavailable
Mar 30 02:47:56 valkyrie upsd[1041]: Send ping to UPS [valkyrie_ups] failed: Resource temporarily unavailable
Mar 30 02:47:56 valkyrie nut-monitor[1063]: Poll UPS [valkyrie_ups@localhost] failed - Variable not supported by UPS
Mar 30 02:47:56 valkyrie nut-server[1041]: Connected to UPS [valkyrie_ups]: usbhid-ups-valkyrie_ups
Mar 30 02:47:56 valkyrie upsd[1041]: Connected to UPS [valkyrie_ups]: usbhid-ups-valkyrie_ups
Mar 30 02:48:01 valkyrie nut-monitor[1063]: Communications with UPS valkyrie_ups@localhost established
Mar 30 02:48:01 valkyrie nut-monitor[1063]: UPS valkyrie_ups@localhost: has at least one unclassified status token: [WAIT]
Mar 30 02:48:13 valkyrie nut-server[1041]: Data for UPS [valkyrie_ups] is stale - check driver
Mar 30 02:48:13 valkyrie upsd[1041]: Data for UPS [valkyrie_ups] is stale - check driver
Mar 30 02:48:16 valkyrie nut-monitor[1063]: Poll UPS [valkyrie_ups@localhost] failed - Data stale
Mar 30 02:48:16 valkyrie nut-monitor[1063]: Communications with UPS valkyrie_ups@localhost lost
Mar 30 02:48:21 valkyrie nut-monitor[1063]: Poll UPS [valkyrie_ups@localhost] failed - Data stale
Mar 30 02:48:26 valkyrie nut-monitor[1063]: Poll UPS [valkyrie_ups@localhost] failed - Data stale
<snip more 5 second spamming>
Mar 30 02:55:38 valkyrie sudo[7577]:    david : TTY=pts/0 ; PWD=/home/david ; USER=root ; COMMAND=/usr/bin/systemctl restart nut-driver@valkyrie_ups
Mar 30 02:55:38 valkyrie nut-driver@valkyrie_ups[7585]: Network UPS Tools upsdrvctl - UPS driver controller 2.8.4 release
Mar 30 02:55:42 valkyrie nut-monitor[1063]: Poll UPS [valkyrie_ups@localhost] failed - Data stale
Mar 30 02:55:43 valkyrie nut-driver@valkyrie_ups[7585]: Stopping /run/nut/usbhid-ups-valkyrie_ups.pid failed, retrying harder: Success
Mar 30 02:55:43 valkyrie nut-server[1041]: Can't connect to UPS [valkyrie_ups] (/var/lib/nut/usbhid-ups-valkyrie_ups): Connection refused
Mar 30 02:55:43 valkyrie upsd[1041]: Can't connect to UPS [valkyrie_ups] (/var/lib/nut/usbhid-ups-valkyrie_ups): Connection refused
Mar 30 02:55:43 valkyrie systemd[1]: nut-driver@valkyrie_ups.service: Main process exited, code=killed, status=9/KILL
Mar 30 02:55:44 valkyrie systemd[1]: nut-driver@valkyrie_ups.service: Failed with result 'signal'.
Mar 30 02:55:44 valkyrie systemd[1]: nut-driver@valkyrie_ups.service: Consumed 1.946s CPU time over 2h 49min 57.511s wall clock time, 6.1M memory peak.
Mar 30 02:55:44 valkyrie systemd[1]: nut-udev-settle.service: Deactivated successfully.
Mar 30 02:55:44 valkyrie nut-driver@valkyrie_ups[7610]: Network UPS Tools upsdrvctl - UPS driver controller 2.8.4 release
Mar 30 02:55:44 valkyrie nut-driver@valkyrie_ups[7627]: Network UPS Tools 2.8.4 release - Generic HID driver 0.67
Mar 30 02:55:44 valkyrie nut-driver@valkyrie_ups[7627]: USB communication driver (libusb 1.0) 0.50
Mar 30 02:55:44 valkyrie nut-driver@valkyrie_ups[7627]: Using subdriver: CyberPower HID 0.84
Mar 30 02:55:44 valkyrie nut-driver@valkyrie_ups[7627]: Defaulting 'pollfreq' to 12 for CPS devices
Mar 30 02:55:44 valkyrie nut-driver@valkyrie_ups[7627]: Listening on socket /var/lib/nut/usbhid-ups-valkyrie_ups
Mar 30 02:55:45 valkyrie nut-server[1041]: Connected to UPS [valkyrie_ups]: usbhid-ups-valkyrie_ups
Mar 30 02:55:45 valkyrie upsd[1041]: Connected to UPS [valkyrie_ups]: usbhid-ups-valkyrie_ups
Mar 30 02:55:47 valkyrie nut-monitor[1063]: Communications with UPS valkyrie_ups@localhost established
Mar 30 02:55:52 valkyrie nut-monitor[1063]: UPS valkyrie_ups@localhost has no unclassified status tokens anymore

Now the driver is up and running again after the restart at Mar 30 02:55:38, but for how long?

Something is not right with the driver communication for either CyberPower CP1350PFCLCD or CP1350AVRLCDa as far as the diver remaining in communication with NUT. With 2.7.4 this was never an issue over 8-10 years of using NUT. Now with the upgrade it looks like there is a regression somewhere. This is a simple "standalone" install. In addition to the ups.conf provided above, the hosts and ups config are (the noc command is just a "no comment" script that strips empty and comment lines from output just to show the configuration lines):

$ noc hosts.conf
MONITOR valkyrie_ups@localhost "Valkyrie CP1350PFCLCD UPS"

$ noc nut.conf
MODE=standalone

The upsd.conf is empty and upsmon.conf (sanitized) is:

# noc upsmon.conf
MONITOR valkyrie_ups@localhost 1 myuser mypass primary
MINSUPPLIES 1
SHUTDOWNCMD "/sbin/shutdown -h +0"
POLLFREQ 5
POLLFREQALERT 5
HOSTSYNC 15
DEADTIME 15
POWERDOWNFLAG "/etc/killpower"
OFFDURATION 30
OVERDURATION -1
RBWARNTIME 43200
NOCOMMWARNTIME 300
FINALDELAY 5
ALARMCRITICAL 1

I'm not sure what else you need me to provide, but ask and I'm happy to get it. The bottom-line issue is why is nut 2.8.4 having problems dropping communication with the usbhid-ups driver where for a decade before the 2.7 version never had any issue whatsoever. Keep up to good work, even with Arjen gone, and let me know what else I can provide.

[jimklimov]

Did you update only NUT or also some other parts of the system? Custom build or packaged installation?

Lines like this in NUT driver log look concerning, and like something beyond NUT:

Mar 30 02:16:55 valkyrie usbhid-ups[912]: nut_libusb_get_report: No such device (it may have been disconnected)

Check if any other software may try to get that port, and if stuff like udev.rules isolates the permissions so only NUT-owned daemons may grab/write to it.

Being USB, it is possible that a port reset caused by someone else (mouse, flash...) ends up as a whole USB hub => bus reset, and device re-enumeration as far as the OS is concerned.

Also, NUT v2.7.4 worked against libusb-0.1 (some packages might ship with libusb-0.1-compat with libusb-1.0 as the actual backend), and this build says it is libusb-1.0 native. Regarding the difference in behavior, it may be possible that the newer library catches errors that the older one ignored or handled somehow differently. You can try custom-building NUT against the older one to compare, that would be interesting (though probably more for libusb devs first) - see https://github.com/networkupstools/nut/wiki/Building-NUT-for-in%E2%80%90place-upgrades-or-non%E2%80%90disruptive-tests for details.

• If you did update not only NUT but also the whole OS/kernel, all those other moving parts like kernel modules may be contributing...
• See if any "USB quirks" that could have been applied in your older kernel (defaults change over the years) might be associated with CPS ID's and might still apply to your (older) device.

Other than that, the CPS name has a long history in this issue tracker associated with unreliable UPS-side controllers that may reset on their own (overheating, misunderstood commands e.g. due to cable noise, etc.) Not necessarily they make bad devices, just they make a lot and some prominent cases become visible on the net. FWIW, try swapping the USB cable for a well shielded one.

[drankinatty]

No, no custom package or anything. This is from the Archlinux provided NUT package. Now the earlier nut 2.7.4 package I upgraded from was one I built years ago. As with everything else Arch, all dependencies, etc. are even with upstream versions, so you can't rule out some new funny business with udev, systemd, etc.. I was really scratching my head. I've used NUT with these UPS, forever, well almost, if you search 'drankinatty' in the list archives it probably goes back over a decade. The old NUT was one of the only packages on the system that I had built and not followed the normal Arch nut package on (it has gone through name changes from network_ups_tools to nut over the years)

I upgraded nut (which I needed to do) due to the 2.7 driver causing a hang on reboot/powerdown (I hadn't rebuilt the nut package in years, the hang was likely due to some kernel workqueue change in 6.18). Rather than being a nut rebel and building my own older package, I just decided to use the package Arch provides (last updated 1/11/2026).

Arch currently has 2.8.5 in the testing-repo and I'll get that as soon as it moves out of the testing repo. There was another Arch user having issues with nut UPS shutdown issue after nut upgrade 2.8.2 -> 2.8.4, but note the Arch list is under "Emergency Moderation" after the systemd 2.61 age-verification inclusion announcement, so there are posts in that thread I've sent that have not yet been blessed clean. (oh joy)

Arch does provide (and I have installed) libusb-compat 0.1.8-2, but all other packages are current with upstream, e.g. linux 6.19.10, systemd 260.1, etc.. I'll see if I can find any of the older USB quirks that may apply, but literally, I had zero problem with nut 2.7 and all kernels, libraries, systemd, etc.. aside from the 90 second hang/timeout on shutdown up to the change to 2.8.4 a few days ago. The driver never lost comm, not once in a decade. The only thing that changed from working nut to driver dropping comm was the update from 2.7.4 to 2.8.4. And yes, it may be some odd issue in another package, which may be fun to chase down.

I'll be damned, it just did it again while I was typing this response, almost a perfect 13 hours later:

Mar 30 02:55:44 valkyrie nut-driver@valkyrie_ups[7627]: Network UPS Tools 2.8.4 release - Generic HID driver 0.67
Mar 30 02:55:44 valkyrie nut-driver@valkyrie_ups[7627]: USB communication driver (libusb 1.0) 0.50
Mar 30 02:55:44 valkyrie nut-driver@valkyrie_ups[7627]: Using subdriver: CyberPower HID 0.84
Mar 30 02:55:44 valkyrie nut-driver@valkyrie_ups[7627]: Defaulting 'pollfreq' to 12 for CPS devices
Mar 30 02:55:44 valkyrie nut-driver@valkyrie_ups[7627]: Listening on socket /var/lib/nut/usbhid-ups-valkyrie_ups
Mar 30 02:55:45 valkyrie nut-server[1041]: Connected to UPS [valkyrie_ups]: usbhid-ups-valkyrie_ups
Mar 30 02:55:45 valkyrie upsd[1041]: Connected to UPS [valkyrie_ups]: usbhid-ups-valkyrie_ups
Mar 30 02:55:47 valkyrie nut-monitor[1063]: Communications with UPS valkyrie_ups@localhost established
Mar 30 02:55:52 valkyrie nut-monitor[1063]: UPS valkyrie_ups@localhost has no unclassified status tokens anymore
Mar 30 15:59:01 valkyrie usbhid-ups[7631]: nut_libusb_get_report: No such device (it may have been disconnected)
Mar 30 15:59:19 valkyrie nut-server[1041]: Data for UPS [valkyrie_ups] is stale - check driver
Mar 30 15:59:19 valkyrie upsd[1041]: Data for UPS [valkyrie_ups] is stale - check driver
Mar 30 15:59:22 valkyrie nut-monitor[1063]: Poll UPS [valkyrie_ups@localhost] failed - Data stale
Mar 30 15:59:22 valkyrie nut-monitor[1063]: Communications with UPS valkyrie_ups@localhost lost
Mar 30 15:59:27 valkyrie nut-monitor[1063]: Poll UPS [valkyrie_ups@localhost] failed - Data stale
Mar 30 15:59:32 valkyrie nut-monitor[1063]: Poll UPS [valkyrie_ups@localhost] failed - Data stale
Mar 30 15:59:37 valkyrie nut-monitor[1063]: Poll UPS [valkyrie_ups@localhost] failed - Data stale

Same start of the issue:

Mar 30 15:59:01 valkyrie usbhid-ups[7631]: nut_libusb_get_report: No such device (it may have been disconnected)

What do you think would be the best course of action? Rebuild nut with debug enabled. Some systemd magic to crank up debug level? Right now all I can do is restart the driver:

$ systemctl restart nut-driver@valkyrie_ups

Broadcast message from nut@valkyrie (somewhere) (Mon Mar 30 16:04:38 2026):

Communications with UPS valkyrie_ups@localhost established

The logs associated with the restart bringing communications back are:

Mar 30 16:04:23 valkyrie nut-monitor[1063]: Poll UPS [valkyrie_ups@localhost] failed - Data stale
Mar 30 16:04:28 valkyrie nut-monitor[1063]: Poll UPS [valkyrie_ups@localhost] failed - Data stale
Mar 30 16:04:28 valkyrie sudo[21759]:    david : TTY=pts/0 ; PWD=/home/david ; USER=root ; COMMAND=/usr/bin/systemctl restart nut-driver@valkyrie_ups
Mar 30 16:04:28 valkyrie nut-driver@valkyrie_ups[21767]: Network UPS Tools upsdrvctl - UPS driver controller 2.8.4 release
Mar 30 16:04:33 valkyrie nut-monitor[1063]: Poll UPS [valkyrie_ups@localhost] failed - Data stale
Mar 30 16:04:33 valkyrie nut-driver@valkyrie_ups[21767]: Stopping /run/nut/usbhid-ups-valkyrie_ups.pid failed, retrying harder: Success
Mar 30 16:04:33 valkyrie nut-server[1041]: Can't connect to UPS [valkyrie_ups] (/var/lib/nut/usbhid-ups-valkyrie_ups): Connection refused
Mar 30 16:04:33 valkyrie upsd[1041]: Can't connect to UPS [valkyrie_ups] (/var/lib/nut/usbhid-ups-valkyrie_ups): Connection refused
Mar 30 16:04:33 valkyrie systemd[1]: nut-driver@valkyrie_ups.service: Main process exited, code=killed, status=9/KILL
Mar 30 16:04:34 valkyrie systemd[1]: nut-driver@valkyrie_ups.service: Failed with result 'signal'.
Mar 30 16:04:34 valkyrie systemd[1]: nut-driver@valkyrie_ups.service: Consumed 11.020s CPU time over 13h 8min 49.512s wall clock time, 4.5M memory peak.
Mar 30 16:04:34 valkyrie systemd[1]: nut-udev-settle.service: Deactivated successfully.
Mar 30 16:04:34 valkyrie nut-driver@valkyrie_ups[21791]: Network UPS Tools upsdrvctl - UPS driver controller 2.8.4 release
Mar 30 16:04:34 valkyrie nut-driver@valkyrie_ups[21808]: Network UPS Tools 2.8.4 release - Generic HID driver 0.67
Mar 30 16:04:34 valkyrie nut-driver@valkyrie_ups[21808]: USB communication driver (libusb 1.0) 0.50
Mar 30 16:04:34 valkyrie nut-driver@valkyrie_ups[21808]: Using subdriver: CyberPower HID 0.84
Mar 30 16:04:34 valkyrie nut-driver@valkyrie_ups[21808]: Defaulting 'pollfreq' to 12 for CPS devices
Mar 30 16:04:34 valkyrie nut-driver@valkyrie_ups[21808]: Listening on socket /var/lib/nut/usbhid-ups-valkyrie_ups
Mar 30 16:04:35 valkyrie nut-server[1041]: Connected to UPS [valkyrie_ups]: usbhid-ups-valkyrie_ups
Mar 30 16:04:35 valkyrie upsd[1041]: Connected to UPS [valkyrie_ups]: usbhid-ups-valkyrie_ups
Mar 30 16:04:38 valkyrie nut-monitor[1063]: Communications with UPS valkyrie_ups@localhost established

I should also add that when nut_libusb_get_report claims no such device, lsusb shows the device there as it always does whether nut is communicating with it or not, e.g.

$ lsusb
Bus 001 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 001 Device 002: ID 045e:0040 Microsoft Corp. Wheel Mouse Optical
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 002: ID 058f:6364 Alcor Micro Corp. AU6477 Card Reader Controller
Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 005 Device 004: ID 0764:0501 Cyber Power System, Inc. CP1500 AVR UPS
Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub

Weird issue, really has me scratching my head? Marching orders for this monkey on my side of the keyboard? I'm will to try anything to debug, just where best to start?

[jimklimov]

For one of the later questions: debug logging is built-in, you just have to dial it up, see https://github.com/networkupstools/nut/wiki/Changing-NUT-daemon-debug-verbosity

Rebuilding "with debug" may make sense to step through code with a debugger, or to read core dumps, but not much outside that activity.

[drankinatty]

Thank you Jim. Will dial-up debugging and see if there is anything of interest to report back. Well, ... I guess I need to create a drop-in for the nut-driver@valkyrie_ups.service file to cranck up debugging, but where? The systemd nut startup has turned into quite the spaghetti of services chained together, e.g.

$ tree /etc/systemd/system/nut*
/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

plus

$ ls -1 /etc/systemd/system/ups*
/etc/systemd/system/upsd.service
/etc/systemd/system/upsmon.service

Yikes, that's 12 targets, services or confs to deal with. 8 of those are "nut-driver..." related. I hate to admit it, but I'm a bit confused at where to insert the debugging option. Any preference?

I brought up systemctl edit nut-driver@valkyrie_ups.service --drop-in=nut-driver@valkyrie_ups.service which brought up all the dependent units commented with a blank space up to add to, but I expected and [exec] ... or the like to modify. Any pointers on where to put the -DDDDD d3 (or the like). Also, since it is likely the driver will connect and run just fine for 10+ hours, is the d3 needed, and how will this service exiting on the 3rd repetition impact all the other services that make up nut?

Update

I've found in ups.conf, upsd.conf and upsmon.conf where additional debug settings can be made. The problem is we are now 29 hours since the last driver communication loss and there is no recurrence yet. No changes to the system since the driver was restarted as shown in the journal snippets above. We'll keep monitoring and see how long it goes before the next event.

Next Event

Spoke too soon. Just a couple hours later the next disconnect occurred:

Mar 30 16:04:34 valkyrie systemd[1]: Started Network UPS Tools - device driver for NUT device 'valkyrie_ups'.
Mar 30 16:04:35 valkyrie nut-server[1041]: Connected to UPS [valkyrie_ups]: usbhid-ups-valkyrie_ups
Mar 30 16:04:35 valkyrie upsd[1041]: Connected to UPS [valkyrie_ups]: usbhid-ups-valkyrie_ups
Mar 30 16:04:35 valkyrie usbhid-ups[21812]: 5:245m5:245msock_connect: enabling asynchronous mode (auto)
Mar 30 16:04:38 valkyrie nut-monitor[1063]: Communications with UPS valkyrie_ups@localhost established
Mar 31 21:47:44 valkyrie usbhid-ups[21812]: 5:245m5:245mnut_libusb_get_report: No such device (it may have been disconnected)
Mar 31 21:48:02 valkyrie nut-server[1041]: Data for UPS [valkyrie_ups] is stale - check driver
Mar 31 21:48:02 valkyrie upsd[1041]: Data for UPS [valkyrie_ups] is stale - check driver
Mar 31 21:48:07 valkyrie nut-monitor[1063]: Poll UPS [valkyrie_ups@localhost] failed - Data stale
Mar 31 21:48:07 valkyrie nut-monitor[1063]: Communications with UPS valkyrie_ups@localhost lost
Mar 31 21:48:12 valkyrie nut-monitor[1063]: Poll UPS [valkyrie_ups@localhost] failed - Data stale
Mar 31 21:48:17 valkyrie nut-monitor[1063]: Poll UPS [valkyrie_ups@localhost] failed - Data stale
...
Mar 31 22:18:38 valkyrie nut-monitor[1063]: Poll UPS [valkyrie_ups@localhost] failed - Data stale
Mar 31 22:18:43 valkyrie nut-monitor[1063]: Poll UPS [valkyrie_ups@localhost] failed - Data stale
Mar 31 22:18:45 valkyrie nut-server[1041]: Send ping to UPS [valkyrie_ups] failed: Resource temporarily unavailable
Mar 31 22:18:45 valkyrie upsd[1041]: Send ping to UPS [valkyrie_ups] failed: Resource temporarily unavailable
Mar 31 22:18:47 valkyrie nut-server[1041]: Connected to UPS [valkyrie_ups]: usbhid-ups-valkyrie_ups
Mar 31 22:18:47 valkyrie upsd[1041]: Connected to UPS [valkyrie_ups]: usbhid-ups-valkyrie_ups
Mar 31 22:18:48 valkyrie nut-monitor[1063]: Communications with UPS valkyrie_ups@localhost established
Mar 31 22:18:48 valkyrie nut-monitor[1063]: UPS valkyrie_ups@localhost: has at least one unclassified status token: [WAIT]
Mar 31 22:19:03 valkyrie nut-server[1041]: Data for UPS [valkyrie_ups] is stale - check driver
Mar 31 22:19:03 valkyrie upsd[1041]: Data for UPS [valkyrie_ups] is stale - check driver
Mar 31 22:19:08 valkyrie nut-monitor[1063]: Poll UPS [valkyrie_ups@localhost] failed - Data stale
Mar 31 22:19:08 valkyrie nut-monitor[1063]: Communications with UPS valkyrie_ups@localhost lost
Mar 31 22:19:13 valkyrie nut-monitor[1063]: Poll UPS [valkyrie_ups@localhost] failed - Data stale
Mar 31 22:19:18 valkyrie nut-monitor[1063]: Poll UPS [valkyrie_ups@localhost] failed - Data stale
...
Mar 31 22:35:49 valkyrie nut-monitor[1063]: Poll UPS [valkyrie_ups@localhost] failed - Data stale
Mar 31 22:35:54 valkyrie nut-monitor[1063]: Poll UPS [valkyrie_ups@localhost] failed - Data stale
Mar 31 22:35:55 valkyrie systemd[1]: Stopping Network UPS Tools - device driver for NUT device 'valkyrie_ups'...
Mar 31 22:35:55 valkyrie nut-driver@valkyrie_ups[53797]: Network UPS Tools upsdrvctl - UPS driver controller 2.8.4 release
Mar 31 22:35:59 valkyrie nut-monitor[1063]: Poll UPS [valkyrie_ups@localhost] failed - Data stale
Mar 31 22:36:00 valkyrie nut-driver@valkyrie_ups[53797]: Stopping /run/nut/usbhid-ups-valkyrie_ups.pid failed, retrying harder: Success
Mar 31 22:36:00 valkyrie nut-server[1041]: Can't connect to UPS [valkyrie_ups] (/var/lib/nut/usbhid-ups-valkyrie_ups): Connection refused
Mar 31 22:36:00 valkyrie upsd[1041]: Can't connect to UPS [valkyrie_ups] (/var/lib/nut/usbhid-ups-valkyrie_ups): Connection refused
Mar 31 22:36:00 valkyrie systemd[1]: 5:185m5:185mnut-driver@valkyrie_ups.service: Main process exited, code=killed, status=9/KILL
Mar 31 22:36:01 valkyrie systemd[1]: 5:185m5:185mnut-driver@valkyrie_ups.service: Failed with result 'signal'.
Mar 31 22:36:01 valkyrie systemd[1]: Stopped Network UPS Tools - device driver for NUT device 'valkyrie_ups'.
Mar 31 22:36:01 valkyrie systemd[1]: nut-driver@valkyrie_ups.service: Consumed 24.932s CPU time over 1d 6h 31min 26.815s wall clock time, 4.7M memory peak.
Mar 31 22:36:01 valkyrie systemd[1]: Starting Network UPS Tools - device driver for NUT device 'valkyrie_ups'...
Mar 31 22:36:01 valkyrie nut-driver@valkyrie_ups[53823]: Network UPS Tools upsdrvctl - UPS driver controller 2.8.4 release
Mar 31 22:36:01 valkyrie nut-driver@valkyrie_ups[53840]: Network UPS Tools 2.8.4 release - Generic HID driver 0.67
Mar 31 22:36:01 valkyrie nut-driver@valkyrie_ups[53840]: USB communication driver (libusb 1.0) 0.50
Mar 31 22:36:01 valkyrie nut-driver@valkyrie_ups[53840]: Using subdriver: CyberPower HID 0.84
Mar 31 22:36:01 valkyrie nut-driver@valkyrie_ups[53840]: Defaulting 'pollfreq' to 12 for CPS devices
Mar 31 22:36:01 valkyrie nut-driver@valkyrie_ups[53840]: You may want to set 'pollonly' flag on CPS devices
Mar 31 22:36:01 valkyrie usbhid-ups[53840]: Defaulting 'pollfreq' to 12 for CPS devices
Mar 31 22:36:01 valkyrie usbhid-ups[53840]: 5:185m5:185mYou may want to set 'pollonly' flag on CPS devices
Mar 31 22:36:01 valkyrie nut-driver@valkyrie_ups[53840]: Listening on socket /var/lib/nut/usbhid-ups-valkyrie_ups
Mar 31 22:36:01 valkyrie usbhid-ups[53840]: Listening on socket /var/lib/nut/usbhid-ups-valkyrie_ups
Mar 31 22:36:01 valkyrie usbhid-ups[53845]: Startup successful
Mar 31 22:36:01 valkyrie usbhid-ups[53845]: 5:245m5:245mupsnotify: notify about state NOTIFY_STATE_READY_WITH_PID with libsystemd: was requested, but not running as a service unit now, will not spam more about it
Mar 31 22:36:01 valkyrie usbhid-ups[53845]: 5:245m5:245mupsnotify: failed to notify about state NOTIFY_STATE_READY_WITH_PID: no notification tech defined, will not spam more about it
Mar 31 22:36:01 valkyrie usbhid-ups[53845]: 5:245m5:245mupsnotify: logged the systemd watchdog situation once, will not spam more about it
Mar 31 22:36:01 valkyrie systemd[1]: Started Network UPS Tools - device driver for NUT device 'valkyrie_ups'.
Mar 31 22:36:02 valkyrie nut-server[1041]: Connected to UPS [valkyrie_ups]: usbhid-ups-valkyrie_ups
Mar 31 22:36:02 valkyrie upsd[1041]: Connected to UPS [valkyrie_ups]: usbhid-ups-valkyrie_ups
Mar 31 22:36:02 valkyrie usbhid-ups[53845]: 5:245m5:245msock_connect: enabling asynchronous mode (auto)
Mar 31 22:36:04 valkyrie nut-monitor[1063]: Communications with UPS valkyrie_ups@localhost established
Mar 31 22:36:04 valkyrie nut-monitor[1063]: UPS valkyrie_ups@localhost has no unclassified status tokens anymore

It briefly reconnected ~30 minutes after the disconnect (Mar 31 22:18:47), but then went down ~16 seconds later until the driver was restarted (Mar 31 22:35:55). So 29 hours 43 seconds is the longest I've been able to keep the 2.8.4 driver connected. I'll see if I can get more debug info this next run.

Possible Clue/Culprit

Checking the journal just before the disconnect, there are kernel messages regarding usb usb5-port3: disabled by hub (EMI?), re-enabling.... I've never heard that one before, EMI, electrical ghosts, etc.. The box and UPS(s) have not moved. They are in the same position with the same equipment next to them. The UPS cable runs from the back of the UPS, besides a computer that is OFF, to the server on top of the computer that is off. A wooden cabinet sits on the other side of the UPS with no electronics in it. The EMI error message looks like a "maybe, possibly, we don't know" great kernel message.

Here are the journal entries leading to the disconnect:

Mar 31 21:47:43 valkyrie kernel: usb usb5-port3: disabled by hub (EMI?), re-enabling...
Mar 31 21:47:43 valkyrie kernel: usb 5-3: USB disconnect, device number 4
Mar 31 21:47:43 valkyrie kernel: usb 5-3: new full-speed USB device number 5 using ohci-pci
Mar 31 21:47:43 valkyrie kernel: usb 5-3: New USB device found, idVendor=0764, idProduct=0501, bcdDevice= 2.00
Mar 31 21:47:43 valkyrie kernel: usb 5-3: New USB device strings: Mfr=3, Product=1, SerialNumber=2
Mar 31 21:47:43 valkyrie kernel: usb 5-3: Product: CP1350AVRLCDa
Mar 31 21:47:43 valkyrie kernel: usb 5-3: Manufacturer: CPS
Mar 31 21:47:43 valkyrie kernel: usb 5-3: SerialNumber: CDNJN2000560
Mar 31 21:47:43 valkyrie kernel: hid-generic 0003:0764:0501.0006: hiddev97,hidraw1: USB HID v1.10 Device [CPS CP1350AVRLCDa] on usb-0000:00:13.0-3/input0
Mar 31 21:47:44 valkyrie usbhid-ups[21812]: nut_libusb_get_report: No such device (it may have been disconnected)
Mar 31 21:48:02 valkyrie nut-server[1041]: Data for UPS [valkyrie_ups] is stale - check driver
Mar 31 21:48:02 valkyrie upsd[1041]: Data for UPS [valkyrie_ups] is stale - check driver
Mar 31 21:48:07 valkyrie nut-monitor[1063]: Poll UPS [valkyrie_ups@localhost] failed - Data stale
Mar 31 21:48:07 valkyrie nut-monitor[1063]: Communications with UPS valkyrie_ups@localhost lost
Mar 31 21:48:12 valkyrie nut-monitor[1063]: Poll UPS [valkyrie_ups@localhost] failed - Data stale
Mar 31 21:48:17 valkyrie nut-monitor[1063]: Poll UPS [valkyrie_ups@localhost] failed - Data stale

(note: there is no separate 'hub', this is just the normal on-montherboard USB, old motherboard, Gigabyte 990FXA-UD3, processor is old Vishera, AMD FX-8350 Eight-core.)

Do the kernel: usb messages add anything usable in tracking down what is happening with the 2.8.4 driver and this UPS? Why can't the driver just reconnect after the usb comes back up?

I haven't tried 2.8.4 on anything other than the Linux 6.19 kernel. The 2.7.4 driver worked with everything from Linux 4.1.5 - Linux 6.19.9. Same cable, nothing has changed. Ideas?

First EMI Complaint 20251009

Checking the journal, the first EMI reset of the USB hub occurred Oct 9, 2025 which corresponded to the updated to the Linux 6.17 kernel. So the 2.7.4 driver had no issue with the EMI reset and was able to reconnect without any problem. When the NUT package was updated to 2.8.4, the driver does not handle the reset properly and never reconnects after a USB hub reset event. I guess that is the main difference that is causing the issue. There is no rhyme or reason to when the EMI disconnect occurs. Sometimes it only occurs 2-3 times per month, other times it could be 30 in a single day, all of which the 2.7.4 driver reconnected and recovered from without issue.

[drankinatty]

Request to close issue

Unless there is a desire to look at why the driver isn't reconnecting after the kernel reset of the USB hub, I will recommend this issue be closed. There is obviously a difference between how the 2.7.4 and 2.8.4 drivers handle the events, but this is likely one of those issues where there probably isn't a good explanation of why. After discovering the EMI issue, I simply tugged on the cable and pulled it about three-inches which may have moved a loop or moved it from an adjacent cat-6 cable, etc. just far enough to remove whatever induced voltage was being picked up as EMI. Since that time I've had no new EMI events and no driver disconnect issue.

While not conclusive on anything, that at least suggests to me that the kernel reported EMI reset was the cause of the disconnect, and while there are no identifiable sources of EMI in the immediate vicinity, moving the cable a couple of inches seems to have eliminated the spurious gibberish on the USB cable.

I had read a couple of other threads investigating this issue with people discussing replacing cables or swapping them and swapping back and the issue having gone away. I'd originally dismissed those posts as one-offs, and not relevant here. But with my last EMI reported Mar 31 21:47:43 just an hour or so prior to me pulling on the USB cable a bit, it seems they were on point. This likely points to poor shielding in the USB cables the UPS manufacturers ship. Either that or gremlins really are real.

Thanks for everybody's help and suggestions. Unless somebody wants to keep this open to look at why the reconnect wasn't happening, I recommend closing this issue. Whatever caused the EMI and disconnect may well have been preventing a normal reconnect of the 2.8.4 driver as well. Without an oscilloscope or any way to capture a trace of the signal on the cable, I doubt there would be any way to recreate the events leading to the disconnect that would make it make sense to try and troubleshoot.

Why am I always the lucky one...

[jimklimov]

Well, loose cables and noise are not a rare culprit of IT issues; re-seating also often helps as it scratches isolating oxide films from the contact points (more so with corrodable ungilded sockets/plugs).

For reproduction of the non-reconnect issue at least as far as when kernel does rediscover the device but NUT (or libusb behind it) does not, that fairly sounds like a NUT bug to address (maybe a regression with reconnect logic, at some point it was IIRC changed to retry same libusb descriptor - but I think it should remember and retry same regex hit criteria too...), and probably physical unplug/replug or software USB reset (uhubctl etc) can emulate the situation close enough.

Keep this open for now.

Can you see from logs if the kernel reported same or different "device number", "hiddev"/"hidraw" numbers, etc. initially and after "EMI" messages?

There's less we can do about cases when the device gets just lost and needs a USB reset to get found again (my own test UPS misbehaved like that recently, randomly going AWOL when its battery was dead, and replacing the battery fixed it back) - that's a too system-specific failure mode and way of recovery for NUT to try (or even be privileged to), and software causIng bus resets is generally frowned upon as that disrupts neighboring hardware, can cause reset storms when that neighbor's software handles connection loss by issuing resets of its own, etc. (similar pain in storage with too-smart drives, backplanes, controllers and kernel drivers all eager to pull a trigger)...

Integrations built over NUT might address such cases though, more holistically than NUT alone ever may.

[drankinatty]

Okay, that reconnect issue also caught my eye as well. If you have a test you want me to run, even something a bland as pulling the cable and seeing if it can recover and how it goes, just let me know how to add whatever debug info and where and I'm happy to provide what I can to help.

[shgubar]

I have been facing this problem for a long time. I have already written about it (1895), but I have not been able to finally solve the problem yet.

I have three UPSs, two of them in one location and one in another location. Voltage stabilizers are installed in two locations. An additional inverter was even installed in one location - just for testing.

From my side, the following steps were taken:

• power cable changed to a thicker one (3x1.5mm2)
• USB cable with ferrites on both sides was replaced
• changed 3 different Raspberry Pi 4 boards
• installed assembled NUT packages (different versions 2.8.x) from Debian SID repositories
• also compiled all these versions myself
• installed separately libusb-dev library
• installed fake-clock so that the time was updated as soon as it was loaded with a small gap from the previous one
• inserted separately RTC-board so that the time was accurate

What are the results: it can run for a month without problems (given that no one touches these devices), or maybe only a few hours.
When trying to restart the service completely (systemctl restart nut.target) it does not solve the problem, more often it says "BAD checksum" and not all data is output via the "upsc" command, like "battery.capacity".
Rebooting the server to which the UPS is connected also does not always solve the problem the first time - almost the same symptoms. But it is the server reboot that helps the duration of trouble-free operation the most.

So it does not work without my intervention.

And finally, I specially installed Debian Buster (it was on this system that I managed to compile NUT version 2.7.4, although the driver in it does not support two simultaneously connected UPSs, I specifically disabled one). And oh, miracle, this combination worked for almost two months without problems. I could not leave it any longer.

I do not know if I helped at all or, on the contrary, created more questions.