Hello, Thanks for your reply.
Both of the services you mentioned ([email protected] and [email protected]) were running. They were spamming syslog with messages like the following: 2024-02-07T14:29:27.704506-05:00 hostname nut-driver@PowervarUPS01[72162]: Network UPS Tools - Generic HID driver 0.47 (2.8.0) 2024-02-07T14:29:27.704537-05:00 hostname nut-driver@PowervarUPS01[72162]: USB communication driver (libusb 1.0) 0.43 2024-02-07T14:29:27.704873-05:00 hostname nut-driver@PowervarUPS01[72161]: Driver failed to start (exit status=1) 2024-02-07T14:29:32.718262-05:00 hostname nut-driver@PowervarUPS01[72167]: Can't claim USB device [4234:0002]@1/0: Invalid parameter 2024-02-07T14:29:32.718386-05:00 hostname nut-driver@PowervarUPS01[72167]: Network UPS Tools - Generic HID driver 0.47 (2.8.0) 2024-02-07T14:29:32.718422-05:00 hostname nut-driver@PowervarUPS01[72167]: USB communication driver (libusb 1.0) 0.43 2024-02-07T14:29:32.718684-05:00 hostname nut-driver@PowervarUPS01[72161]: Driver failed to start (exit status=1) 2024-02-07T14:29:32.718829-05:00 hostname nut-driver@APCUPS01[72166]: Can't claim USB device [051d:0002]@1/0: Invalid parameter After stopping those services I ran the driver again from the CLI with the same result. That "Invalid parameter" is conspicuous. I haven't seen it in anyone else's questions or answers. The only place i've seen it in relation to this problem is in libusb1.c (on github), but not in a way that makes it obvious how to track down the cause. I suspect some sort of version or parameter mismatch somewhere in libusb, but I have no idea how to test for that. On Wed, Feb 7, 2024, at 12:57 PM, Jim Klimov wrote: > Hello and welcome! > > My guess would be that a nut-driver service unit (or instances thereof > since NUT v2.8.0, monolithic before) have started and captured the devices, > so your attempts with another copy of the driver started from CLI fail at > that. Normally drivers detect an older sibling running (by poking a PID > file), but service units may forgo creation of one. (Since 2.8.1 they can > also try to use driver-server protocol locally.) > > Since NUT v2.8.0 there is a nut-driver-enumerator (script and service) > which manages creation, deletion and reloading/restarting of unit instances > based on ups.conf contents (start-up) or changes (run-time). Check if you > have `[email protected]` (and `...@APCUPS01`) there to fit > this bill? If yes, then to experiment with CLI copies of drivers, `systemctl > stop` such unit(s). > > Hope this helps, > Jim Klimov > > > On Wed, Feb 7, 2024, 14:48 Jason Doolittle <[email protected]> wrote: >> I am working in Ubuntu Linux on a Raspberry Pi 5. Nut is unable to connect >> to USB UPSs. >> >> uname -srvmpio >> Linux 6.5.0-1009-raspi #12-Ubuntu SMP PREEMPT_DYNAMIC Wed Jan 17 11:45:08 >> UTC 2024 aarch64 aarch64 aarch64 GNU/Linux >> >> Current Installed version of nut is 2.8.0-7 installed with apt >> >> apt-cache policy nut >> nut: >> Installed: 2.8.0-7 >> Candidate: 2.8.0-7 >> Version table: >> *** 2.8.0-7 500 >> 500 http://ports.ubuntu.com/ubuntu-ports mantic/main arm64 Packages >> 100 /var/lib/dpkg/status >> >> I currently have 2 UPSs connected to the system >> A Powervar UPM UPS >> Bus 003 Device 002: ID 4234:0002 AMETEK-POWERVAR Corporation UPM UPS >> (v01.51, Nov 3 2018) >> >> An APC Back-UPS Pro 1500 >> Bus 001 Device 002: ID 051d:0002 American Power Conversion Uninterruptible >> Power Supply >> >> It appears that the all of the permissions were set up correctly during >> installation. The nut user and group were created and the usb devices have >> the correct ownership and permissions set per the udev rules >> >> For the Powervar: >> crw-rw-r-- 1 root nut 189, 257 Feb 7 06:42 /dev/bus/usb/003/002 >> >> For the APC: >> crw-rw-r-- 1 root nut 189, 1 Feb 7 06:42 /dev/bus/usb/001/002 >> >> In ups.conf, I have this: >> >> [PowervarUPS01] >> driver = "usbhid-ups" >> port = "auto" >> vendorid = "4234" >> productid = "0002" >> >> [APCUPS01] >> driver = "usbhid-ups" >> port = "auto" >> vendorid = "051D" >> productid = "0002" >> >> The UPSs are matched, but drivers continuously fail to start. Here is the >> output from running the usbhid-ups driver manually for the Powervar: >> >> sudo /usr/lib/nut/usbhid-ups -u root -a PowervarUPS01 -DD >> >> Network UPS Tools - Generic HID driver 0.47 (2.8.0) >> USB communication driver (libusb 1.0) 0.43 >> 0.000000 [D1] debug level is '2' >> 0.001191 [D2] Initializing an USB-connected UPS with library >> libusb-1.0.26 (API: 0x1000109) (NUT subdriver name='USB communication driver >> (libusb 1.0)' ver='0.43') >> 0.001209 [D1] upsdrv_initups (non-SHUT)... >> 0.006358 [D2] Checking device 1 of 6 (1D6B/0003) >> 0.006385 [D1] Failed to open device (1D6B/0003), skipping: Access denied >> (insufficient permissions) >> 0.006393 [D2] Checking device 2 of 6 (4234/0002) >> 0.007354 [D2] - VendorID: 4234 >> 0.007364 [D2] - ProductID: 0002 >> 0.007371 [D2] - Manufacturer: AMETEK-POWERVAR Corporation >> 0.007378 [D2] - Product: UPM UPS (v01.51, Nov 3 2018) >> 0.007385 [D2] - Serial Number: 5008094R-1940438 >> 0.007395 [D2] - Bus: 003 >> 0.007402 [D2] - Device: unknown >> 0.007409 [D2] - Device release number: 0002 >> 0.007418 [D2] Trying to match device >> 0.007425 [D2] match_function_subdriver (non-SHUT mode): matching a >> device... >> 0.007485 [D2] Device matches >> 0.007497 [D2] Reading first configuration descriptor >> 0.007505 [D2] result: -5 (Entity not found) >> 0.007517 [D2] failed to claim USB device: Entity not found >> 0.007529 [D1] failed to detach kernel driver from USB device: Invalid >> parameter >> 0.007539 [D2] failed to claim USB device: Entity not found >> 0.007549 [D1] failed to detach kernel driver from USB device: Invalid >> parameter >> 0.007560 [D2] failed to claim USB device: Entity not found >> 0.007574 [D1] failed to detach kernel driver from USB device: Invalid >> parameter >> 0.007582 [D2] failed to claim USB device: Entity not found >> 0.007594 [D1] failed to detach kernel driver from USB device: Invalid >> parameter >> 0.007604 Can't claim USB device [4234:0002]@1/0: Invalid parameter >> >> I get basically the same from the APC. >> >> I think the "failed to detach kernel driver from USB device: Invalid >> parameter" is the key here, especially the "Invalid parameter" part, but >> after a few hours of poking at things, I haven't made any progress. >> >> I would be eternally grateful if someone could point me in the right >> direction. >> >> _______________________________________________ >> Nut-upsuser mailing list >> [email protected] >> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser >>
_______________________________________________ Nut-upsuser mailing list [email protected] https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
