Hello everyone, Weeks ago I purchased a UPS unit for my home server. It's attached to the machine via a usb port:
uhidev0 at uhub3 port 2 configuration 1 interface 0 "EATON Eaton 3S" rev 2.00/1.00 addr 2 uhidev0: iclass 3/0, 32 report ids upd0 at uhidev0 At first I used NUT from packages but once I became aware of upd(4) already gives me the needed info: hw.sensors.upd0.indicator4=On (ACPresent), OK hw.sensors.upd0.percent0=100.00% (RemainingCapacity), OK ... I simply run a shell script from cron to halt the machine when the battery is low. It has been working for days (with and without NUT) apparently without problems except for three times in which the usb signal from the ups got cut, apparently for no reason. I get this message in console: upd0 detached uhidev0 detached While using NUT I got "stale" messages from upsmon when that happened. What I Investigated So Far -------------------------- NUT usbhid-ups driver man page mentions some workaround: https://networkupstools.org/docs/man/usbhid-ups.html pollfreq=num Set polling frequency, in seconds, to reduce the USB data flow. Between two polling requests, the driver will wait for interrupts (aka UPS notifications), which are data changes returned by the UPS by itself. This mechanism allow to avoid or reduce staleness message, due to the UPS being temporarily overloaded with too much polling requests. The default value is 30 (in seconds). But, since the issue happens erratically, so far I couldn't realize if that solves the problem (if it does, it would be possible to teach upd(4) to do something alike?) On the Internet some NUT users mention issues with libusb. There is an old tutorial about using NUT in OpenBSD that advices to install libusb-compat but, given the current nut package doesn't install it as a dependency I assumed it's not longer necessary. There is an item in libusb-compat package info that explains: $ pkg_info libusb-compat [...] 4. Some libusb-0.1 users may have implemented I/O cancellation by running transfers in their own threads and simply killing the thread when they don't want to do the transfer any more. This is bad programming practice for obvious reasons, and this lack of functionality was one of the primary drivers for libusb-1.0 development. With libusb-1.0 or libusb-compat-0.1 backed by libusb-1.0, forcefully killing threads in this way is likely to cause all libusb I/O to halt. Instead, port your application to use libusb-1.0's asynchronous transfer API, which supports transfer cancellation. Is this related? If someone knows where the problem is I'd appreciate any advice. Walter
