Description of problem: When I upgraded from 2.6.16-1.2133_FC5 to 2.6.17-1.2139_FC5 (both smp on a dual athlon system) newhidups would no longer detect my usb attached UPS (an MGE Systems Nova 1100). I downgraded the kernel and it started working again. Version-Release number of selected component (if applicable): 2.6.16-1.2133_FC5 How reproducible: always Steps to Reproduce: 1. service ups restart 2. 3. Actual results: [root@bruno updates]# service ups restart Stopping UPS monitor: [ OK ] Stopping upsd: [ OK ] Shutting down upsdrvctl: Network UPS Tools - UPS driver controller 2.1.0 Can't open /var/run/nut/newhidups-ups.pid: No such file or directory Starting upsdrvctl: Network UPS Tools - UPS driver controller 2.1.0 Network UPS Tools: New USB/HID UPS driver 0.28 (2.1.0) No matching USB/HID UPS found Driver failed to start (exit status=1) [FAILED] Starting upsd: Network UPS Tools upsd 2.1.0 Can't connect to UPS [ups] (ups): No such file or directory Synchronizing........ giving up [ OK ] Starting UPS monitor (master): Network UPS Tools upsmon 2.1.0 UPS: ups@localhost (master) (power value 1) Using power down flag file /etc/killpower [ OK ] Expected results: I expected that newhidups would be running. Additional info: This is with both nut-2.0.3-0.1.fc5 and an upstream 2.1 snapshot I was testing that is supposed to fix a problem with newhidups in 2.0.3. Here are the related logs in /var/log/messages: Jul 1 12:05:29 bruno upsd[3396]: Can't connect to UPS [ups] (ups): No such file or directory Jul 1 12:05:34 bruno upsd[3397]: Startup successful Jul 1 12:05:34 bruno upsmon[3400]: Startup successful Jul 1 12:05:34 bruno upsd[3397]: Connection from 127.0.0.1 Jul 1 12:05:34 bruno upsd[3397]: Client monuser.0.1 logged into UPS [ups]Jul 1 12:05:34 bruno upsmon[3401]: Poll UPS [ups@localhost] failed - Driver not connected Jul 1 12:05:34 bruno upsmon[3401]: Communications with UPS ups@localhost lost Jul 1 12:05:34 bruno wall[3404]: wall: user nut broadcasted 1 lines (44 chars) Jul 1 12:05:39 bruno upsmon[3401]: Poll UPS [ups@localhost] failed - Driver not connected Jul 1 12:05:39 bruno upsmon[3401]: UPS ups@localhost is unavailable Jul 1 12:05:39 bruno wall[3407]: wall: user nut broadcasted 1 lines (34 chars) Jul 1 12:05:44 bruno upsmon[3401]: Poll UPS [ups@localhost] failed - Driver not connected Jul 1 12:06:19 bruno last message repeated 7 times Jul 1 12:07:24 bruno last message repeated 13 times
I tried out kernel-2.6.17-1.2339.fc6 and it also has the same problem.
I was able to get newhidups to work with kernel-smp-2.6.17-1.2139_FC5 eventaully. So I am pretty sure the problem is my fault and not a bug. I suspect that I wasn't getting back to a clean spot when doing some of my tests and so I wasn't testing the conditions I thought I was and thought some combinations of kernel and nut were working when they weren't (because of the test version of nut, not the kernel) and in other cases that they weren't working (with the supported version of nut) when they were. So I am going to resolve this as "not a bug". Sorry for the noise.
This is just FYI, but I think I figured out how I managed to get confused. It seems as if when newhidups is started (at least for the supported 2.0.3 version), it leaves something running even if it is uninstalled and the ups service is restarted. So I think the order I did things was this: Got nut 2.0.3 running on 2.6.16. Installed nut 2.1 from nut development, but didn't reboot and things were still working. Upgraded to 2.6.17 kernel at which point things stopped working. Tried switching back to nut-2.0.3, still broken because I didn't reboot. Switched back to 2.6.16 and then things were working again (because of the reboot, not the downgrade).
One more FYI update on this. I did get nut 2.1 to work on 2.6.17 by having the daemons run as root. I think what the sticky status might be, is access to the usb device. The nut development rpm may not have provided that access to user 'nut', while the fedora rpm did. That seems like it would be something that would stay until a reboot.
This is the last followup to this. I did find there was udev rules file installed by the FC nut rpm that wasn't installed by the one from nut development, and this was the source of my problems. Now that I have that file in place everything is working as expected.