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>