[Nut-upsuser] confusion about shutdown

[Jim Klimov]

https://github.com/networkupstools/nut/pull/1762 (and maybe some of other
recent PRs) updated quite a bit here and there, including a configure-time
option for default POWERDOWNFLAG value (using legacy default still).

Distros now have easier time to put it into a tmpfs of their choice that
they know will remain mounted.

Jim

On Thu, Jan 5, 2023, 19:03 Greg Troxel <gdt at lexort.com> wrote:

> 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.
>
> _______________________________________________
> Nut-upsuser mailing list
> Nut-upsuser at alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/nut-upsuser/attachments/20230105/b6a7e58a/attachment.htm>