[arch-general] Do packages built on libusb need rebuilding on libusbx? upsd won't stay connected over usb.
Guys, Update yesterday caused network-ups-tools to fail (upsd). I have 2 x86_64 servers running upsd. The one I did not update continues to work, but the one I updated yesterday does not. So I have a working install to compare to. The install that fails -- starts just fine, but then loses communication with the ups for some reason: Jun 8 11:16:51 nirvana upsd[13963]: listening on 192.168.6.17 port 3493 Jun 8 11:16:51 nirvana upsd[13963]: listening on 127.0.0.1 port 3493 Jun 8 11:16:51 nirvana upsd[13964]: Startup successful Jun 8 11:16:51 nirvana upsmon[13966]: Startup successful Jun 8 11:16:56 nirvana upsmon[13967]: Communications with UPS nirvana_ups@localhost lost Jun 8 11:16:56 nirvana wall[13969]: wall: user nut broadcasted 1 lines (52 chars) Jun 8 11:17:01 nirvana upsmon[13967]: UPS nirvana_ups@localhost is unavailable Jun 8 11:17:01 nirvana wall[13972]: wall: user nut broadcasted 1 lines (42 chars) It uses the usbhid module and it is successfully loaded: 11:39 nirvana:~/arch/pkg/bld> lsmod | grep usbhid usbhid 36142 1 hid 84549 1 usbhid usbcore 146847 5 ehci_hcd,ohci_hcd,usbhid However, when I try and talk to the ups, I get: 11:39 nirvana:~/arch/pkg/bld> upsc nirvana_ups Error: Driver not connected The network-ups-tools wiki mentions that an incorrect state path could cause this problem. I checked before updating yesterday and /var/lock and /var/run were both proper symlinks before running the filesystem update with --force. That leaves me looking at either libusb -> libusbx or udev/smartd-tools issues. It looks like there is an issue with the way usb is now handled. Running: $ sudo usbhid-ups -u root -DD -a nirvana_ups <snip> Trying to match device Device matches failed to claim USB device: Device or resource busy detached kernel driver from USB device... HID descriptor length 387 Report Descriptor size = 387 Using subdriver: CyberPower HID 0.2 Path: UPS.PowerSummary.iProduct, Type: Feature, ReportID: 0x01, Offset: 0, Size: 8, Value: 1.000000 Path: UPS.PowerSummary.iSerialNumber, Type: Feature, ReportID: 0x02, Offset: 0, Size: 8, Value: 2.000000 Path: UPS.PowerSummary.iDeviceChemistry, Type: Feature, ReportID: 0x03, Offset: 0, Size: 8, Value: 4.000000 <snip> upsd connects fine, gets the correct value from the UPS and then doesn't stay connected? Does this sound like a libusb -> libusbx issue? If so, what do I need to do to fix it? Rebuild against libusbx, bug report? What say the gurus? -- David C. Rankin, J.D.,P.E.
On 06/08/2012 03:13 PM, David C. Rankin wrote:
Guys,
Update yesterday caused network-ups-tools to fail (upsd). I have 2 x86_64 servers running upsd. The one I did not update continues to work, but the one I updated yesterday does not. So I have a working install to compare to. The install that fails -- starts just fine, but then loses communication with the ups for some reason: <snip>
The network-ups-tools wiki mentions that an incorrect state path could cause this problem. I checked before updating yesterday and /var/lock and /var/run were both proper symlinks before running the filesystem update with --force.
OK, I've isolated the issue, now how do I solve it. The problem is upsdrvctl cannot start usbhid-ups anymore. You must manually start 'usbhid-ups -u root' instead of just calling usbhid-ups. Something in the updates yesterday caused this issue and I can't figure out what -- need help. Further calling 'usbhid-ups -u root' creates the state files under /var/state/ups to be created as root:root instead of nut:nut which causes the subsequent calls to upsd and upsmon to fail. The init script for upsd has always worked as follows: stat_busy "Starting UPSd Daemon" /usr/bin/upsdrvctl start &> /dev/null [ -z "$PID" ] && /usr/sbin/upsd &>/dev/null /usr/sbin/upsmon &>/dev/null if [ $? -gt 0 ]; then stat_fail else add_daemon upsd stat_done fi ;; However, after whatever changed in the updates, the only way to start upsd is with: # /usr/bin/usbhid-ups -u root -a nirvana_ups # chown nut:nut /var/state/ups/* # /usr/sbin/upsd # /usr/sbin/upsmon If you try starting usbhid-ups without '-u root', that results in the driver not being able to fine the UPS giving the error: "No matching HID UPS found", but giving -u root allows it to find the UPS just fine. What could have altered the ability of usbhid-ups to start without the -u root option? libusbx? filesystem update? Any help would be greatly appreciated. In the mean time, I can just hack the init script to get it started, but I don't understand what caused this to be necessary. It's not an upstream issue, something changed with Arch.... Thanks for any assistance. -- David C. Rankin, J.D.,P.E.
On Fri, 08 Jun 2012 17:21:14 -0500 David C. Rankin wrote:
In the mean time, I can just hack the init script to get it started,
The question would be, doest that pose a greater security risk. Have you tried using -u nut. If that fails I'd use systrace (strace on Linux) or something to see why it fails.
On 06/09/2012 08:41 AM, Kevin Chadwick wrote:
The question would be, doest that pose a greater security risk.
Have you tried using -u nut.
If that fails I'd use systrace (strace on Linux) or something to see why it fails.
Thanks Kevin, Yes, I tried '-u nut' and it fails the same as no '-u user' at all. All of this looks like some file permission on some device or something changed, but every file/device I look at, the permissions are the same between working/non-working box. I'll have to go try and dust off my debugging capabilities. If you think of anything else, let me know :) -- David C. Rankin, J.D.,P.E.
On 10 juin 2012, at 02:27, David C. Rankin wrote:
On 06/09/2012 08:41 AM, Kevin Chadwick wrote:
The question would be, doest that pose a greater security risk.
Have you tried using -u nut.
If that fails I'd use systrace (strace on Linux) or something to see why it fails.
Thanks Kevin,
Yes, I tried '-u nut' and it fails the same as no '-u user' at all. All of this looks like some file permission on some device or something changed, but every file/device I look at, the permissions are the same between working/non-working box. I'll have to go try and dust off my debugging capabilities. If you think of anything else, let me know :)
-- David C. Rankin, J.D.,P.E.
Have you looked to the usb device permission? After the latest upgrade I did (kernel, libusbx, systems-tools and a lot of other stuffs), upsd wouldn’t connect. But as described on the AUR page, the package must be recompiled, with an addition to the configure command to put the udev rules in the correct directory. Cf. http://aur.archlinux.org/packages.php?ID=5379 Best regards. -- Nicolas D (a.k.a slubman)
On 06/09/2012 07:37 PM, slubman wrote:
Have you looked to the usb device permission?
After the latest upgrade I did (kernel, libusbx, systems-tools and a lot of other stuffs), upsd wouldn’t connect.
But as described on the AUR page, the package must be recompiled, with an addition to the configure command to put the udev rules in the correct directory.
Cf. http://aur.archlinux.org/packages.php?ID=5379
Best regards.
-- Nicolas D (a.k.a slubman)
Thanks Nicolas, Yes, I incorporated that into the PKGBUILD before rebuilding: build() { cd $srcdir/nut-$pkgver ./configure --with-user=nut \ --prefix=/usr \ --datadir=/usr/share/ups \ --sysconfdir=/etc/ups \ --with-group=nut \ --with-hal \ --with-usb \ --with-udev-dir=/etc/udev || return 1 That looked right, but now doesn't make sense since the rules are in pkg/lib/udev/rules.d/52-nut-usbups.rules. The new post today to the AUR package corrects the issue: "Those udev rules were moved to /usr/lib/udev/rules.d, so --with-udev-dir=/usr/lib/udev might be a better option." That makes sense -- I'll give it a go. -- David C. Rankin, J.D.,P.E.
On 06/09/2012 11:57 PM, David C. Rankin wrote:
"Those udev rules were moved to /usr/lib/udev/rules.d, so --with-udev-dir=/usr/lib/udev might be a better option."
That makes sense -- I'll give it a go.
Tried, still failed - out of brain power for this evening -- will work on it again tomorrow. -- David C. Rankin, J.D.,P.E.
On 10 juin 2012, at 07:12, David C. Rankin wrote:
On 06/09/2012 11:57 PM, David C. Rankin wrote:
"Those udev rules were moved to /usr/lib/udev/rules.d, so --with-udev-dir=/usr/lib/udev might be a better option."
That makes sense -- I'll give it a go.
Tried, still failed - out of brain power for this evening -- will work on it again tomorrow.
-- David C. Rankin, J.D.,P.E.
After installing the package seth the udev rules in a good directory, have you make udev reload those rules? For that you can issue this command: udevadm trigger Then check for the device permissions. -- Nicolas D (aka slubman)
On 06/10/2012 05:36 AM, slubman wrote:
After installing the package seth the udev rules in a good directory, have you make udev reload those rules?
For that you can issue this command: udevadm trigger Then check for the device permissions.
Thank you Nicolas, I will see if I can dig further in the next day or so. Every time I think I have time to dig into it, another bomb goes off somewhere else :) We will get to the bottom of it sooner or later. -- David C. Rankin, J.D.,P.E.
participants (3)
-
David C. Rankin
-
Kevin Chadwick
-
slubman