Charles Lepple <clep...@gmail.com> writes: > On Dec 30, 2022, at 7:42 PM, Greg Troxel <g...@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@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser