[Nut-upsuser] confusion about shutdown
Greg Troxel
gdt at lexort.com
Thu Jan 5 18:02:53 GMT 2023
Charles Lepple <clepple at gmail.com> writes:
> On Dec 30, 2022, at 7:42 PM, Greg Troxel <gdt at lexort.com> wrote:
>>
>> maybe me, maybe docs.
>>
>> I have never had auto shutdown set up on netbsd. Mostly I monitor to
>> mqtt. But now I'm trying and have multiple confusions.
>>
>> 1) 'upsdrvctl shutdown' vs 'upscmd shutdown.return'
>>
>> upsdrvctl is about stopping the driver, but lowbatt shutdown wants to
>> send a command. I don't get the upsmon example file:
>
> "upsdrvctl stop" is for stopping the driver, but "upsdrvctl shutdown"
> runs "$DRIVER -k" to kill power to the load on the UPS (which is
> actually a second, non-long-running instance of the driver that
> doesn't talk to upsd, after the rest of the system is ready to stop).
>
> That being said, upscmd needs to talk to upsd, which needs a running
> driver - IMHO this is only workable if you trust your
> delay-before-shutdown in the UPS. The "upsdrvctl shutdown" case can
> often be run after everything has been remounted read-only, at which
> point it is okay if there is no delay before the power gets pulled.
Thanks. I am editing docs for a soon PR. Checking my understanding:
psdrvctl stop will not affect the UPS, and upsdrvctl shutdown will spin
up $driver -k, assuming that the previous long-running driver is no
longer running.
And thus one does not use upscmd to do a shutdown, because it needs
upsd/driver running and in getting to fs being ro, those will have been
stopped.
And, one can either:
do shutdown when upsd/driver/upsmon is stopped and hope delay is long
enough
or
have another script that runs essentially last, after the fs are ro,
so even if no delay it's ok
> Hopefully explained by the above. Also, you don't have to check for the file directly - you can use "upsmon -K" as in the following excerpt from the rc.d/nut script in FreeBSD's NUT port:
>
> nut_poststop() {
> if ${nut_prefix}/sbin/upsdrvctl stop && checkyesno nut_upsshut; then
> if ${nut_prefix}/sbin/upsmon -K; then
> ${nut_prefix}/sbin/upsdrvctl shutdown
> fi
> fi
>
> }
got it about -K
This assumes delay, or is that somehow post remount ro?
>> 2) LB config. On a Best Fortress, I can set lowbatt runtime, but only
>> 3 digits, even though I want 1800s. Is this likely a Fortress
>> limitation, or a bug? I will read the source...
>
> Looks like it might be a NUT bug. There should be room for four digits
> in the protocol, but the protocol appears to be minutes. NUT shouldn't
> limit the seconds field to three characters.
Thanks, will read the printed protocol spec I have someplace.
>> 2A) seems like nut should be able to have time-based config to start
>> shutdown, all of batt%, seconds remaining, and seconds on battery, built
>> in.
>
> Others have covered solutions in greater depth (I think Roger's config
> guide handles most of these), but IMHO things like "seconds on
> battery" aren't as easy as they look (unless you don't care about the
> intersection with seconds remaining).
Sure, I want:
if on batt for 2min, start shutdown
and I'm fine with
if LB, start shutdown
also firing. Basically one UPS has a desktop (piggy, not important to
stay up, important not to break) and an RPI/switch/wifi (good to keep
running).
I have queued the config examples pdf for reading.
>> 3) seems like shutdown should remove /etc/killpower but maybe upsmon
>> removes it at boot. should be explained more, probably, guessing it is
>> at boot since fs is ro
>
> probably should be removed at boot (or better yet, placed on a RAM-based filesystem), but this is not my area of expertise.
/etc is ~never RAM-based, so we need to move to /var/run or equiv, but I
think removing it at startup is easy and maybe already done. I will
look.
More information about the Nut-upsuser
mailing list