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 <[email protected]> wrote: > Charles Lepple <[email protected]> writes: > > > On Dec 30, 2022, at 7:42 PM, Greg Troxel <[email protected]> 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 > [email protected] > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser >
_______________________________________________ Nut-upsuser mailing list [email protected] https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
