Nut upsuser - Dec 2013 - APC Smart-UPS 1500; system shutdown is not initiated.

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 at 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

On Dec 8, 2013, at 10:41 PM, Christian wrote:
> test.battery.start.deep - Start a deep battery test
> test.battery.start.quick - Start a quick battery test
Ideally, you would want to do a deep test with a dummy load, like a lamp, so as
not to put your server in danger of getting cut off again. You can probably do
the test.battery.start.quick test with the server still plugged into the UPS,
though.

-- 
Charles Lepple
clepple at gmail

Charles,

the unit has two redundant power supplies, with only one hooked up to
the UPS. So I should be able to do a deep test with the machine itself,
right? I have tried it, but it aborts at some point...

For the quick test, it discharges the battery a bit, then recharges, but
once it is back to 100%, upsc still gives me:

ups.test.result: No test initiated

Is that expected?

Best,

Christian

Am 17.12.2013 03:55, schrieb Charles Lepple:
> On Dec 8, 2013, at 10:41 PM, Christian wrote:
> 
>> test.battery.start.deep - Start a deep battery test 
>> test.battery.start.quick - Start a quick battery test
> 
> Ideally, you would want to do a deep test with a dummy load, like a 
> lamp, so as not to put your server in danger of getting cut off 
> again. You can probably do the test.battery.start.quick test with
> the server still plugged into the UPS, though.
>