[Nut-upsuser] Nut-upsuser Digest, Vol 231, Issue 2

Jim Klimov jimklimov+nut at gmail.com
Sat Sep 7 22:27:36 BST 2024


Cheers, jumping into the discussion late from some travels, sorry.

In the original post, is the "Server PC" the OMV with NUT? Are any of your
other machines running NUT (e.g. the `upsmon` client for shutdowns)?

What I guess may be happening is:

* OMV has the physical connection needed to monitor and command the UPS,
and its `upsmon` has `MONITOR` for it as `primary` (ex-`master`);
* by definition, such a "primary" instance in case of a power outage (and
"critical state" of the UPS battery, definitions vary) is responsible for
yelling "FSD" (Forced ShutDown) to all other "secondary" clients connected
to tge same `upsd` data server (maybe none in your case), waiting for them
all (if any) to disconnect - presumably meaning they are going down, and
shuts down itself.
* With the "killpower" file in place (created as part of "primary" FSD
handling), and some OS shutdown integration, it would also tell all
connected UPSes to power off (or power-cycle if power came back, aka "power
race condition", to avoid your systems staying down indefinitely), if the
UPS and its NUT driver agree how to support such behavior.

This seems aligned with what you see in practice.

One quick fix can be to change the OMV `MONITOR` mode to `secondary`
(ex-`slave`) so only it shuts down when power goes "bad".

Nuanced criteria for the latter, like time spent on battery, can be set in
`upssched` (as asked about by Roger). Default "bad"ness is defined by UPS
itself claiming a low battery state, maybe also by remaining percentage
(depends on driver and device).

Hope this helps,
Jim Klimov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/nut-upsuser/attachments/20240907/07616461/attachment.htm>


More information about the Nut-upsuser mailing list