<div dir="ltr"><div><div><div><div>Hello again :)<br><br>>
Aren't the drivers daemonized and isn't it the drivers that kill power already?<span class="gmail-im"><br><br></span></div><span class="gmail-im">Historically, a mixed bag: they are daemonized while monitoring, then they exit (or are killed) as part of shutdown, and then a late-shutdown script (historically a patch to rc.halt or similar init-script - this integration depends a lot on the OS and its service management framework, whether we can inject late-shutdown logic at all) would check that we are in FSD mode and then would call the driver binary again which connects to the device again and tells it to power off.<br><br></span></div><span class="gmail-im">With recent work on master branch, a possibility was introduced to use the running driver daemon to send such a command to the UPS; however it would need some rework of OS integration to not kill the daemon, retain the communication sockets available, etc. - so probably not something instantly usable for the out-of-the-box shutdown routine today.<br><br>> </span>
The manual makes a significant point of the idea that when an FSD event occurs, everything should be shut down and the power cut so that the UPS later will power everything back up again, whereas if some consumers are shut down early, they won't automatically
come back up.<br><span class="gmail-im"><br></span></div><span class="gmail-im">To my knowledge, that stance remains. It is generally complicated to orchestrate revival of a rack full of servers from partially-off state, with some databases depending on storage and apps depending on databases, etc. - and especially with legacy systems lacking some cross-server service health and dependency tracking. So the safe approach is to power everything off and then start up consistently and predictably. After all, this chain of events is something tested by every power-on of the data room, unlike any other random situations :) Of course, if a particular deployment can take advantage of their local tools (say, everything is a single Kubernetes farm and all nodes know each other's health), solutions specific to such use-cases can differ from NUT's generally suggested safe default behavior. If blueprints to such optimized solutions can be shared as part of NUT FAQ or Wiki - so much the better :)<br><br></span></div><div><span class="gmail-im">Regarding power coming back after our shutdown began, and if we can not power-cycle the UPS when this routine ends (e.g. poor hardware support), then other than WoL packets, the late-shutdown integration noted above can also be used (if it can) on the NUT-client systems. If an upsmon client has caused an FSD shutdown, the client system can just sleep for a long time and reboot programmatically. If the battery dies during this time - no loss. If the UPS stays up, servers come back after some time.</span></div><div><span class="gmail-im"></span></div><div><div><div><div><br>> I figure it'd be better if the primary could shut down as soon as it's safe to do so rather than waiting for a fixed amount of time.<br></div><div><br></div><div>Here we balance opposing goals :) If you want the heavy-weight secondary servers to take time for a shut down
(assuming battery can handle it), before the NUT primary is green-lit to proceed with its shut-down and complete it by cutting the UPS power, then you wait for all secondary upsmons to log off. As soon as they do, it is considered safe for the primary to proceed (it does not wait "for a fixed time" beyond that).<br></div><div><br></div><div>Currently the primary does wait for a (configurable) fixed time and proceed with its shutdown even if secondaries did not log off.</div><div><br>
Makes sense for such a primary to not have long-stopping services of its
own, which would rely on some large-file consistency etc. - the battery
would be running on fumes during its shutdown and power might disappear
any time. Something lightweight (service-wise) like a firewall machine
or a dedicated Raspberry might be a good choice.
Perhaps some integration via upssched (or further development work in upsmon; or maybe using a separate secondary upsmon client with a special SHUTDOWNCMD on the same machine) could ensure that the NUT primary host would stop its heavy services (if any) as soon as it tells other clients to stop themselves. This way there would be nothing important running except NUT on this primary system by the time that the primary upsmon proceeds to shut down its host server.<br><br></div><div>As part of this discussion,
<a href="https://github.com/networkupstools/nut/pull/2133" target="_blank">https://github.com/networkupstools/nut/pull/2133</a> was merged and added a way for the secondary upsmons to NOT exit as soon as they called their SHUTDOWNCMD - now alternatives exist for upsmon to wait for a specified time and then exit, or to never exit on its own accord (but to honour e.g. a SIGTERM when its OS service is finally told to go down, up to the sysadmins to make sure this happens after all the heavy services are safely parked). This is available on master branch now, and should be part of NUT v2.8.1 release soon.<br></div><div><br></div><div>Hope this helps,<br></div><div><span class="gmail-im"></span></div><div><span class="gmail-im">Jim Klimov<br></span></div><div><span class="gmail-im"><br></span>
</div></div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Oct 31, 2023 at 11:27 AM Magnus Holmgren <<a href="mailto:magnus.holmgren@milientsoftware.com">magnus.holmgren@milientsoftware.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">fredag 27 oktober 2023 20:07:58 CET skrev Jim Klimov:<br>
> Hi, this does sound like a useful idea - although for the principle of<br>
> least surprise and for variation in deployments, I'd rather have it as a<br>
> (non-default state of a) configuration toggle that can be set via<br>
> `upsmon.conf`: whether this particular client exits after processing FSD or<br>
> not. The onus for the rest would be on general systems integration - e.g.<br>
> ensure that init scripts `K*`ill the long-running services before they go<br>
> after upsmon and upsd, or add a drop-in systemd config snippet for<br>
> nut-monitor to not-conflict with "shutdown.target" (and half a dozen of its<br>
> equivalents for halt/reboot/poweroff/...), and possibly to break the<br>
> shutdown-dependency between nut-monitor/nut-server/nut-driver units.<br>
<br>
Yes, I figure this is up to the distributions to get right.<br>
<br>
> On a related note - there was lately work to allow daemonized drivers to<br>
> kill power of the UPS (may be useful especially for devices with long<br>
> protocol init times), with a safety switch to flip about this and actually<br>
> allow the driver to issue killpower commands. So stopping driver daemons<br>
> might eventually be not needed - but I'm not sure any OS integrations took<br>
> note of this possibility yet. It was not officially released so far, just<br>
> is in master branch.<br>
<br>
I don't understand what you're saying here. Aren't the drivers daemonized and <br>
isn't it the drivers that kill power already?<br>
<br>
> Note however that typically FSD happens when the power is critical.<br>
> Definitions of that vary, as well as ability or not to set certain<br>
> thresholds for when the device would emit (and a driver would relay) the<br>
> low-battery condition. You might not physically have those 2 minutes worth<br>
> of remaining battery charge to shut down the VMs or other long-stopping<br>
> services (e.g. app servers to flush in-flight operations, and only later<br>
> their databases) - more so with the probable storage I/O and power-draw<br>
> burst to flush out databases or hibernate those VMs.<br>
<br>
Obviously I'll have to set the LB threshold to give sufficient margin, but i <br>
figure it'd be better if the primary could shut down as soon as it's safe to <br>
do so rather than waiting for a fixed amount of time. Though I'd still need to <br>
ensure that the battery can last for as long as the primary will wait.<br>
<br>
> In this case fiddling with upssched or setting up dummy-ups relays with an<br>
> override for defining earlier trigger of critical state (usually by battery<br>
> charge or time remaining) may fare better: your NUT primary server would<br>
> seem to serve several UPSes (the "real" device and a few dummies with<br>
> different "criticality" levels), and various secondary hosts would MONITOR<br>
> the suitable dummy to begin their shutdown earlier into the outage. This<br>
> approach may also be useful for Dan's post :)<br>
<br>
Ah, that seems like a workable way of shutting down different machines based <br>
on different battery levels. One caveat though: The manual makes a significant <br>
point of the idea that when an FSD event occurs, everything should be shut <br>
down and the power cut so that the UPS later will power everything back up <br>
again, whereas if some consumers are shut down early, they won't automatically <br>
come back up (unless you arrange for WoL packets to be sent out, or <br>
something).<br>
<br>
> Jim<br>
> <br>
> On Fri, Oct 27, 2023 at 4:55 PM Magnus Holmgren <<br>
> <br>
> <a href="mailto:magnus.holmgren@milientsoftware.com" target="_blank">magnus.holmgren@milientsoftware.com</a>> wrote:<br>
> > Hi, and thanks for this great piece of free software! I've been meaning to<br>
> > sort this out for some time, but we don't get power outages that often,<br>
> > fortunately...<br>
> > <br>
> > So, correct me if I'm wrong, but from the documentation at https://<br>
> > <a href="http://networkupstools.org/docs/user-manual.chunked/" rel="noreferrer" target="_blank">networkupstools.org/docs/user-manual.chunked/</a><br>
> > Configuration_notes.html#UPS_shutdown, and also reading upsmon.c, when a<br>
> > UPS<br>
> > goes OB LB (assuming we have a single UPS connected to a primary and<br>
> > supplying<br>
> > power to the primary and some number of secondaries), the primary notifies<br>
> > the<br>
> > secondaries, the secondaries wait for FINALDELAY and then execute<br>
> > SHUTDOWNCMD<br>
> > immediately followed by exiting, thereby disconnecting from the primary,<br>
> > and<br>
> > the primary, after seeing all secondaries disconnect, proceed with its<br>
> > shutdown (only waiting for FINALDELAY), which ends with telling the UPS to<br>
> > cut<br>
> > the power (without delay too, right?).<br>
> > <br>
> > Again, correct me if I'm wrong, Is it only I who find this a bit flawed? I<br>
> > would like for the secondaries to stay connected until they shut down. We<br>
> > have<br>
> > a server with a bunch of virtual machines on, and they can take a couple<br>
> > of<br>
> > minutes to shut down. Otherwise the primary can easily cut the power<br>
> > prematurely. Avoiding this, it seems, could pretty easily be accomplished<br>
> > by<br>
> > having upsmon wait, perhaps in a separate loop, for the INT/TERM/QUIT<br>
> > signal<br>
> > (it would still be necessary to configure the service manager such that<br>
> > upsmon<br>
> > is terminated as late as possible). The primary could start shutting down<br>
> > its<br>
> > services in the meantime, but upsmon would hold the poweroff until the<br>
> > secondaries have disconnected (or HOSTSYNC expires).<br>
> > <br>
> > Surely this would be better than cranking up FINALDELAY on the primary and<br>
> > always waiting for a fixed period of time, as suggested in<br>
> > <a href="https://alioth-lists.debian.net/pipermail/nut-upsuser/2012-April/007550.ht" rel="noreferrer" target="_blank">https://alioth-lists.debian.net/pipermail/nut-upsuser/2012-April/007550.ht</a><br>
> > ml? I guess I could<br>
> > try writing a SHUTDOWNCMD script that doesn't exit until most other<br>
> > services<br>
> > have also done so, taking care not to create a deadlock situation.<br>
> > <br>
> > Another option would be to use upssched to shut down the "big rig"<br>
> > earlier. It<br>
> > just seems unsatisfying to me that upssched is entirely time-based. It<br>
> > would<br>
> > be nice if it were easier to trigger off battery.charge or battery.runtime<br>
> > going below arbitrary values instead of just the on battery and low<br>
> > battery<br>
> > statuses.<br>
> > <br>
> > How do others solve this?<br>
<br>
-- <br>
Magnus Holmgren<br>
./¯\_/¯\. Milient<br>
<br>
<br>
<br>
<br>
</blockquote></div>