Bug 197443 - 2.6.17-1.2139_FC5 breaks newhidups for my usb attached ups
2.6.17-1.2139_FC5 breaks newhidups for my usb attached ups
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
5
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Pete Zaitcev
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-07-01 13:07 EDT by Bruno Wolff III
Modified: 2007-11-30 17:11 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-07-04 12:40:12 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Bruno Wolff III 2006-07-01 13:07:31 EDT
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@127.0.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
Comment 1 Bruno Wolff III 2006-07-04 01:35:15 EDT
I tried out kernel-2.6.17-1.2339.fc6 and it also has the same problem.
Comment 2 Bruno Wolff III 2006-07-04 12:40:12 EDT
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.
Comment 3 Bruno Wolff III 2006-07-04 14:11:29 EDT
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).
Comment 4 Bruno Wolff III 2006-07-04 17:14:42 EDT
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.
Comment 5 Bruno Wolff III 2006-07-04 21:35:51 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.