[Nut-upsuser] FSD sequence: Waiting for bigger and slower clients before cutting power

[Magnus Holmgren]

Hi, and thanks for this great piece of free software! I've been meaning to 
sort this out for some time, but we don't get power outages that often, 
fortunately...

So, correct me if I'm wrong, but from the documentation at https://
networkupstools.org/docs/user-manual.chunked/
Configuration_notes.html#UPS_shutdown, and also reading upsmon.c, when a UPS 
goes OB LB (assuming we have a single UPS connected to a primary and supplying 
power to the primary and some number of secondaries), the primary notifies the 
secondaries, the secondaries wait for FINALDELAY and then execute SHUTDOWNCMD 
immediately followed by exiting, thereby disconnecting from the primary, and 
the primary, after seeing all secondaries disconnect, proceed with its 
shutdown (only waiting for FINALDELAY), which ends with telling the UPS to cut 
the power (without delay too, right?).

Again, correct me if I'm wrong, Is it only I who find this a bit flawed? I 
would like for the secondaries to stay connected until they shut down. We have 
a server with a bunch of virtual machines on, and they can take a couple of 
minutes to shut down. Otherwise the primary can easily cut the power 
prematurely. Avoiding this, it seems, could pretty easily be accomplished by 
having upsmon wait, perhaps in a separate loop, for the INT/TERM/QUIT signal 
(it would still be necessary to configure the service manager such that upsmon 
is terminated as late as possible). The primary could start shutting down its 
services in the meantime, but upsmon would hold the poweroff until the 
secondaries have disconnected (or HOSTSYNC expires).

Surely this would be better than cranking up FINALDELAY on the primary and 
always waiting for a fixed period of time, as suggested in https://alioth-lists.debian.net/pipermail/nut-upsuser/2012-April/007550.html? I guess I could 
try writing a SHUTDOWNCMD script that doesn't exit until most other services 
have also done so, taking care not to create a deadlock situation.

Another option would be to use upssched to shut down the "big rig" earlier. It 
just seems unsatisfying to me that upssched is entirely time-based. It would 
be nice if it were easier to trigger off battery.charge or battery.runtime 
going below arbitrary values instead of just the on battery and low battery 
statuses.

How do others solve this?

-- 
Magnus Holmgren
./¯\_/¯\. Milient
(also holmgren at debian.org)