On 3/24/26 5:03 PM, Łukasz Michalski wrote:
I've reported it and it seems that this will be fixed in 2.8.5, so no
need to update wiki.
https://github.com/networkupstools/nut/issues/3364
Good deal,
I've also had another issue with 2.8.4 that I wonder if you see. This
server has a CP1350PFCLCD that has been working without issue for years.
After update, all seemed well (other than the odd driver state after
update that caused a commanded shutdown). The following reboot, the
driver came up fine. It connected and did not lose communication at all.
Today we had an extended power outage and NUT did it's job and shut
down the server. However, on reboot, the nut-driver would not stay
connected resulting in the driver connecting but then losing
communication. The broadcast messages were:
Broadcast message from nut@valkyrie (somewhere) (Fri Mar 27 19:39:38 2026):
Communications with UPS valkyrie_ups@localhost established
Broadcast message from nut@valkyrie (somewhere) (Fri Mar 27 19:39:38 2026):
UPS valkyrie_ups@localhost: has at least one unclassified status token:
[WAIT]
Broadcast message from nut@valkyrie (somewhere) (Fri Mar 27 19:39:48 2026):
Communications with UPS valkyrie_ups@localhost lost
This was frustrating as I did not want another commanded shutdown due
to driver state. I scrambled and finally found restarting the driver did
in fact bring the driver back online and it has remained connected. e.g.
# systemctl restart nut-driver@valkyrie_ups
Are you seeing any inconsistency in how the driver startup on boot
leaves the driver connected/not connected? When this occurred I checked
with lsusb and the UPS was listed as it always was:
# lsusb
<snip>
Bus 005 Device 013: ID 0764:0501 Cyber Power System, Inc. CP1500 AVR UPS
But still, NUT was not communicating with it until I restarted the
driver service. Any thoughts on why or what to check to ensure I get a
consistent driver startup?
Looking at the journal, on boot, the driver startup that failed and
then connected on restart looks like it just failed to connect on boot
for whatever reason, but then on restart was happy to connect, e.g.
boot:
Mar 27 19:07:51 valkyrie systemd[1]: nut-udev-settle.service:
Deactivated successfully.
Mar 27 19:07:55 valkyrie nut-driver@valkyrie_ups[746]: Network UPS Tools
upsdrvctl - UPS driver controller 2.8.4 release
Mar 27 19:07:55 valkyrie nut-driver@valkyrie_ups[830]: Network UPS Tools
2.8.4 release - Generic HID driver 0.67
Mar 27 19:07:55 valkyrie nut-driver@valkyrie_ups[830]: USB communication
driver (libusb 1.0) 0.50
Mar 27 19:07:55 valkyrie nut-driver@valkyrie_ups[830]: Using subdriver:
CyberPower HID 0.84
Mar 27 19:07:55 valkyrie nut-driver-enumerator[747]: Sat Mar 28 12:07:55
AM UTC 2026 : OK: No changes to reconcile between systemd service
instances and device configurations in '/etc/nut/ups.conf'
Mar 27 19:07:55 valkyrie systemd[1]: nut-driver-enumerator.service:
Deactivated successfully.
Mar 27 19:07:55 valkyrie nut-driver@valkyrie_ups[830]: Defaulting
'pollfreq' to 12 for CPS devices
Mar 27 19:07:55 valkyrie nut-driver@valkyrie_ups[830]: You may want to
set 'pollonly' flag on CPS devices
Mar 27 19:07:55 valkyrie nut-driver@valkyrie_ups[830]: Listening on
socket /var/lib/nut/usbhid-ups-valkyrie_ups
...
Mar 27 19:08:31 valkyrie usbhid-ups[887]: nut_libusb_get_interrupt: No
such device (it may have been disconnected)
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
Mar 27 19:08:52 valkyrie nut-monitor[954]: Communications with UPS
valkyrie_ups@localhost lost
Mar 27 19:08:57 valkyrie nut-monitor[954]: Poll UPS
[valkyrie_ups@localhost] failed - Data stale
...
nut-driver restart:
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
All good from that point forward. What makes no sense is on the boot
before, it came up fine and stayed connected, this boot it didn't. That
seems like something I need to solve. It's not a disconnect/reconnect
race, it's just a didn't connect, so the pollonly flag wouldn't be a
fix. I'll keep an eye on it next boot. If you have any idea, let me know.
--
David C. Rankin, J.D.,P.E.
