[Nut-upsuser] Two APC UPS deivces, Fedora, slightly lost

Sat May 2 17:36:47 BST 2026

It doesn’t seem to start the driver for the 1050g2. Device

# systemctl restart nut-driver at 1050g2
Job for nut-driver at 1050g2.service failed because the control process exited with error code.
See "systemctl status nut-driver at 1050g2.service" and "journalctl -xeu nut-driver at 1050g2.service" for details.

Journalctl for the driver
May 02 17:33:49 cracker systemd[1]: nut-driver at 1050g2.service: Scheduled restart job, restart counter is at 1.
May 02 17:33:49 cracker systemd[1]: Starting nut-driver at 1050g2.service - Network UPS Tools - device driver for 1050g2...
May 02 17:33:49 cracker nut-driver at 1050g2[12320]: Network UPS Tools upsdrvctl - UPS driver controller 2.8.4 release
May 02 17:33:49 cracker nut-driver at 1050g2[12350]: Network UPS Tools 2.8.4 release - Generic HID driver 0.67
May 02 17:33:49 cracker nut-driver at 1050g2[12350]: USB communication driver (libusb 1.0) 0.50
May 02 17:33:49 cracker nut-driver at 1050g2[12350]: Can't claim USB device [051d:0002]@0/0/0: Other error
May 02 17:33:49 cracker nut-driver at 1050g2[12350]: upsnotify: notify about state NOTIFY_STATE_STOPPING with libsystemd: was requested, but not running as a service unit now, will not spam more about it
May 02 17:33:49 cracker nut-driver at 1050g2[12320]: Driver failed to start (exit status=1)

And the 850g2
# systemctl restart nut-driver at 850g2
Job for nut-driver at 850g2.service failed because the control process exited with error code.
See "systemctl status nut-driver at 850g2.service" and "journalctl -xeu nut-driver at 850g2.service" for details

May 02 17:34:32 cracker nut-driver at 850g2[12874]: Network UPS Tools 2.8.4 release - Generic HID driver 0.67
May 02 17:34:32 cracker nut-driver at 850g2[12874]: USB communication driver (libusb 1.0) 0.50
May 02 17:34:32 cracker nut-driver at 850g2[12874]: Can't claim USB device [051d:0002]@0/0/0: Other error
May 02 17:34:32 cracker nut-driver at 850g2[12874]: upsnotify: notify about state NOTIFY_STATE_STOPPING with libsystemd: was requested, but not running as a service unit now, will not spam more about it
May 02 17:34:32 cracker nut-driver at 850g2[12817]: Driver failed to start (exit status=1)
May 02 17:34:32 cracker systemd[1]: nut-driver at 850g2.service: Control process exited, code=exited, status=1/FAILURE
May 02 17:34:32 cracker systemd[1]: nut-driver at 850g2.service: Failed with result 'exit-code'.
May 02 17:34:32 cracker systemd[1]: Failed to start nut-driver at 850g2.service - Network UPS Tools - device driver for 850g2.

What does this “other error” mean ? How is this driver attempting to access the device(s) ?

These device files are accessible by he nut group:

[root at cracker ~]# ls -lrt /dev/bus/usb/001/00*
crw-rw-r-- 1 root root 189, 0 May  2 17:19 /dev/bus/usb/001/001
crw-rw---- 1 root nut  189, 2 May  2 17:35 /dev/bus/usb/001/003
crw-rw---- 1 root nut  189, 8 May  2 17:35 /dev/bus/usb/001/009
[root at cracker ~]#

From: Charles Lepple <clepple at gmail.com>
Sent: 30 April 2026 12:25
To: Gavin Davenport <gavdav at gavdav.net>
Cc: Nut-upsuser <nut-upsuser at alioth-lists.debian.net>
Subject: Re: [Nut-upsuser] Two APC UPS deivces, Fedora, slightly lost

I haven't used NUT on Fedora, but your ups.conf seems to be on the right track (symlinks will not help for devices supported by usbhid-ups).

There are not many USB product IDs for APC UPSes, but do you get different IDs from "lsusb -d 051d:? Matching product IDs uses simpler logic than matching strings.

A while back, we had issues with Linux guests not getting all of the USB information when on an ESXi hypervisor. That may not be the case if your host machine is physical, but there is still a possibility that the driver is having trouble during the stage when it iterates through all of the USB devices to retrieve strings like serial numbers. Check the logs for any messages saying that the driver couldn't read the serial number - probably from something like "journalctl -t usbhid-ups". Specifics of increasing the driver debug level may depend on your version of NUT (and whether/how the packager changed the systemd service definitions).

If that doesn't work, you can try plugging the UPSes into different USB ports (i.e. not into a hub) and using the "bus" parameter in ups.conf, which may need to be adjusted after a major kernel upgrade if the USB stack enumerates the buses in a different order.

--
Charles Lepple
clepple at gmail

On Apr 29, 2026, at 6:55 PM, Gavin Davenport <gavdav at gavdav.net<mailto:gavdav at gavdav.net>> wrote:

I have 2 APC UpS devices – I have a group of 4 machines connected to various outputs on them and they are connected by USB to the same fedora host.

I’m having issues with nut reliabl discovering both devices

Here’s my ups.conf

  [850g2]
      driver = usbhid-ups
      port = auto
      desc = "APC Back-UPS ES 850G2"
      serial = 5B1932T42066

  [1050g2]
      driver = usbhid-ups
      port = auto
      desc = "APC Back-UPS BE1050G2"
      serial = 9B2545A15277

I’m hoping nut will match on the serial number of the device.

I’ve been rather led astray by chatgpt making stuff up and then forgetting where it is – so I’m a bit confused about whether I try to have udev prepare the appropriate symlinks for nut

I’ve had this working (2 Ups devices being monitored, but all a bit hand-cranked). I can’t get it to survive a reboot.

Are there any known issues with using 2 APC Ups devices which announce themselves very similarly ?
_______________________________________________
Nut-upsuser mailing list
Nut-upsuser at alioth-lists.debian.net<mailto:Nut-upsuser at alioth-lists.debian.net>
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/nut-upsuser/attachments/20260502/fc0ed4c1/attachment-0001.htm>