[Nut-upsuser] Shutdown when both (all) UPS on battery / low battery

[Charles Lepple]

On Jan 23, 2014, at 2:33 AM, Rafal Oleszek wrote:

>> On Jan 21, 2014, at 9:27 AM, Rafal Oleszek wrote:
>> 
>>> So it's impossible to configure upssched to start timer only if all ups
>>> are in status: OB or LB ?
>> 
>> Not impossible, just not possible inside a single configuration file.
>> You can always put that logic into an external script called by upssched.
> 
> NUT is installed only on one server and scripts (to order shutdown
> environment) are called by upssched when UPS_251 and UPS_252 change state
> into OB (first script) and LB (second script). But NUT isn't waiting for
> both UPS. Just start timer when only one goes on OB. Maybe it is working
> only for SHUTDOWNCMD?

Correct, SHUTDOWNCMD in upsmon is considering MINSUPPLIES and the powervalue numbers. By manipulating MINSUPPLIES, you can get either a Boolean AND or OR of all the LB states.

NOTIFYCMD (which triggers upssched) is only triggering on one UPS at a time.

> In manual there is a section about timers: * mean that if ANY of ups goes
> OB it start proceed. Maybe that why it's not waiting for both UPS?


Yes, but you can start two timers, and wait for OB status on both UPSes using logic in your upssched CMDSCRIPT script.

I admit that in your setup, there appears to be some asymmetry between upsmon and upssched when handling OB/LB states. However, the LB case does not have the added complication of timers. One reason I tend to not rely on OB for anything other than notifications is that the UPS calibration routines should track any decrease in battery runtime when triggering an LB event. If the battery runtime were to fall below the timer values, the system would have an uncontrolled shutdown.

If your UPS supports adjusting the LB threshold, I would consider raising battery.charge.low and/or battery.runtime.low, and starting the shutdown sequence at that point. (In contrast to the battery runtime, your shutdown procedure times will likely not change unexpectedly over the long term.)

-- 
Charles Lepple
clepple at gmail