<div dir="auto">Cheers, jumping into the discussion late from some travels, sorry.<div dir="auto"><br></div><div dir="auto">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)?</div><div dir="auto"><br></div><div dir="auto">What I guess may be happening is:</div><div dir="auto"><br></div><div dir="auto">* OMV has the physical connection needed to monitor and command the UPS, and its `upsmon` has `MONITOR` for it as `primary` (ex-`master`);</div><div dir="auto">* 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.</div><div dir="auto">* 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.</div><div dir="auto"><br></div><div dir="auto">This seems aligned with what you see in practice.</div><div dir="auto"><br></div><div dir="auto">One quick fix can be to change the OMV `MONITOR` mode to `secondary` (ex-`slave`) so only it shuts down when power goes "bad".</div><div dir="auto"><br></div><div dir="auto">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).</div><div dir="auto"><br></div><div dir="auto">Hope this helps,</div><div dir="auto">Jim Klimov</div><div dir="auto"><br></div></div>