[Nut-upsuser] No shutdown on empty battery

Arnaud Quette aquette.dev at gmail.com
Tue Feb 7 15:56:44 UTC 2012

Hi Gerhard,

2012/2/4 Gerhard Strangar <g.s at arcor.de>:
> Arnaud Quette wrote (2012-02-02 14:13):
> I did a test with an older version of my UPS, same model, but no USB
> connector. This time, everything worked fine:
> Feb  4 12:01:37 b1 upsmon[1494]: UPS upsb1 at localhost on battery
> Feb  4 12:18:52 b1 upsmon[1494]: UPS upsb1 at localhost battery is low
> Feb  4 12:18:52 b1 upsmon[1494]: Executing automatic power-fail shutdown
> Feb  4 12:18:52 b1 upsmon[1494]: Auto logout and shutdown proceeding
> [...]
> Feb  4 12:19:06 b1 upsd[1480]: mainloop: Interrupted system call
> [...]
> Feb  4 12:19:10 b1 syslogd: exiting on signal 15
>> /etc/killpower is cleared at upsmon startup, in case it exists.
> It was this time, but not when the shutdown had failed.
>> you have not answered to my question on where "upsdrvctl shutdown" is
>> called in the process?
>> as told, on Debian, it's handled by the halt script.
> It's in /usr/local/etc/rc.d/nut, which is called when entering shutdown
> "runlevel".
> I watched the upsc output during that test. It started with

do you mean the battery test, or the procedure to test a shutdown
sequence, without having your computer powered by the UPS?

> ups.beeper.status: enabled
> ups.status: ALARM OB
> I disabled the beeper with the button at the fron panel, but it still
> said enabled.
> The LOAD_DUMPED output is nonsense, this UPS cannot dump load (except
> for dumping everything, which it didn't) and the battery was not totally
> discharged when I started the test.

LOAD_DUMPED should be mapped to "ups.status" = "OFF", which means that
output are not powered anymore.
was there any power on the output so?

> Later on it said:
> battery.charge: 70
> battery.runtime: 95
> battery.voltage: 10.49
> ups.status: FSD ALARM OB LB
> So finally, the utility which was not present (see above) now failed. :-)

if this was not the battery test, how long has it take to reach this state?
if it was the battery test, it should not cause this with a 30 seconds
I'm still thinking about depleted batteries.

> I guess, Ill configure that timer thing, just to be sure shutdown works.

beware that timer has a static approach that may work for some time...
but then fail if your total runtime decrease over time.
it's always better to understand the issue, and actually fix it.

I would need a debug output of the driver for the above test, Ie:
$ /path/to/bcmxcp_usb -DDDDD -a upsb1

and an upsc output, to get the general context (ups.load, base
battery.runtime, ...).

Linux / Unix Expert R&D - Eaton - http://powerquality.eaton.com
Network UPS Tools (NUT) Project Leader - http://www.networkupstools.org/
Debian Developer - http://www.debian.org
Free Software Developer - http://arnaud.quette.free.fr/

More information about the Nut-upsuser mailing list