[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

And, one can either:

  do shutdown when upsd/driver/upsmon is stopped and hope delay is long


  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

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

More information about the Nut-upsuser mailing list