On Mon, 15 Nov 2021, Kari Lempiainen wrote:
What would be the preferred way to do some operations just before UPS is about
to lose its power? I need to shut down some remote devices which are connected
to the same UPS as my Nut server. They are not "NUT compatible" so I need to
prepare them for losing power with some scripts. The complete shutdown of
these devices takes about 120-150 seconds.
My first instinct was to call those scripts from the SHUTDOWNCMD. Then I
realised that Nut might ask UPS to shut down before that. But this could be
modified by offdelay in ups.conf, right?
There are two approaches to shutting down on power failure: 1: wait until the
UPS has reached LOWBATT status; 2: wait some number of seconds after ONBATT is
detected.
Option 1 is simpler and is the most common. However if you go this way, you
take the risk of battery exhaustion before the remote devices have shut down.
You can mitigate this by raising battery.charge.low using command upsrw if your
UPS allows this.
Second thought was to NOTIFYCMD and upssched.conf with upssched-cmd script.
And catch the LOWBATT event there and call my shutdown scripts. Then I read
that even that could be interrupted by system (and UPS) shutdown, before
letting LOWBATT event to do it's magic.
Option 2 using NOTIFYCMD is more complex to set up but will give you more
assurance that the remote devices are shutdown correctly, particularly in the
case of repeated power failures.
Is it really so that there is no "safe" way to deal with notification event
LOWBATTERY?
Even if you use option 2, NUT is still capable of detecting [ob lb] and invoking
it's built-in shutdown procedure. However this would only happen after
excessive repeated power failures.
Will Nut start the shutdown procedure around same time when it receives "[ob
lb]" from UPS and it doesn't wait for LOWBATTERY event to be processed? I know
that in my setup UPS will have power for more than 180 seconds after reaching
20% battery level.
So is the only safe option to use ONBATT event and use START-TIMER method with
upssched.conf?
Option 2 is probably "safer" for shutting down remote devices, when shutting
them down takes a significant part of the UPS survival time, but since it looks
as if you have a sufficiently large UPS, try option 1, raise battery.charge.low
and do lots of testing.
Roger
_______________________________________________
Nut-upsuser mailing list
[email protected]
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
