Charles, thanks for your detailed answer.
>> Occasionally, i get these in daemon.log: Dec 4 03:11:54 afs1 >> usbhid-ups[21973]: libusb_get_interrupt: could not claim interface >> 0: Device or resource busy > > This isn't great, but I don't think it's related. > > It is normal to get a "could not claim interface 0" error once after > the USB cable is first plugged into a Linux box. When usbhid-ups > starts up, if it gets that error, it has to detach the kernel HID > driver. After that point (until the USB cable is unplugged or the > box is rebooted), you shouldn't see that error. I don't think you > should see it from the libusb_get_interrupt function, either. I'd > check the logs here, but the usbhid-ups driver is running on a BSD > box at the moment, which doesn't have the same problem as Linux. > > How often do you see it? This is does not appear following any plugging in or unplugging. It appears roughly once a day, though not exactly regularly or at a specific time of day. The box is in a locked server cabinet and nobody is touching it. > Is there a possibility of another program trying to access the UPS? Not that I know of. >> Dec 6 11:50:55 afs1 usbhid-ups[21973]: libusb_get_interrupt: error >> sending control message: Connection timed out > > We increased the USB timeout in 2.7.1, so this should go away after > upgrading. > > These sorts of transient errors are not a problem unless you get > several in a row, and the driver should log a different message at > that point. That is certainly not the case. >> afs1:/var/log# upsc apc@localhost battery.charge: 100 >> battery.charge.low: 10 battery.charge.warning: 50 >> battery.mfr.date: 2008/05/22 > > ^ If this date is accurate (and I don't know for sure if our code > can reliably update this), then you may want to consider a new > battery. Although an UPS battery doesn't see the extreme temperature > cycling that a car battery does, it does typically run a few degrees > above ambient, and the lead-acid chemistry is only good for 3-5 years > of reliable service. The date is correct. Though the UPS with the battery had been sitting on a shelf in the basement unused for a significant fraction of that time... >> [...] ups.test.result: No test initiated > > ^ Occasional battery tests are needed to ensure that the calibration > values can predict when the battery is about to run out. > > Some info is here: > > http://forums.apc.com/thread/8669 > > If you post the output of 'upscmd -l apc', we can try to figure out > which calibration command would be the best to try. afs1:~# upscmd -l apc Instant commands supported on UPS [apc]: beeper.disable - Disable the UPS beeper beeper.enable - Enable the UPS beeper beeper.mute - Temporarily mute the UPS beeper beeper.off - Obsolete (use beeper.disable or beeper.mute) beeper.on - Obsolete (use beeper.enable) load.off - Turn off the load immediately load.off.delay - Turn off the load with a delay (seconds) load.on - Turn on the load immediately load.on.delay - Turn on the load with a delay (seconds) shutdown.reboot - Shut down the load briefly while rebooting the UPS shutdown.return - Turn off the load and return when power is back shutdown.stayoff - Turn off the load and remain off shutdown.stop - Stop a shutdown in progress test.battery.start.deep - Start a deep battery test test.battery.start.quick - Start a quick battery test test.battery.stop - Stop the battery test test.panel.start - Start testing the UPS panel test.panel.stop - Stop a UPS panel test Thanks, Christian _______________________________________________ Nut-upsuser mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
