Nut upsuser - Jun 2019 - How to shutdown macOS / mac OSX from Network UPS Tools client - NUT

On Jun 8, 2019, at 4:16 PM, Roger Price wrote:
> 
> Is your System Shutdown Plan to shut down using upsmon or using the script
upsched-cmd?  In upssched.conf you do not have a line
> 
> AT LOWBATT ups at ... EXECUTE lowbatt
> 
> and in upssched-cmd there is nothing to shut down the system.
Joe,

Roger has a good point - the SHUTDOWNCMD should work as long as the master
system waits for the "OB LB" state, and doesn't shut down early
(say, at 30% battery remaining, but the UPS waits for 20% before declaring LB).

I have never used a Synology box, but I vaguely remember them not using the NUT
LB state. (That might have been covered in one of your links, but I haven't
had a chance to look through all of them.)

-- 
- Charles Lepple
https://ghz.cc/charles/

Thanks Roger and Charles for your responses.

Simple question first
> > Have you tried typing the command "/sbin/shutdown -u -h +1"
directly?  Does this perform a shutdown?
Yes, it does shutdown the iMac.
> >   Is your System Shutdown Plan to shut down using upsmon or using the
script upsched-cmd?
This question undermines my reading of the documentation.  I had thought that
these were separate things:

    SHUTDOWNCMD "/sbin/shutdown -u -h +1" 
    NOTIFYCMD /opt/local/sbin/upssched

I had assumed that the SHUTDOWNCMD would be used by the Nut client (upsmon) to
shutdown the slave system,  and that the NOTIFYCMD would be responsible for
notifying users of what is going on.

But I am now inferring from your question, that use of the NOTIFYCMD supersedes
or overrides the functionality of the former.  Is that correct?  So if I use a
NOTIFYCMD, then I should implement the actual shutdown logic as well as the
notification logic in that script, forgetting about SHUTDOWNCMD?
> > I have never used a Synology box, but I vaguely remember them not
using the NUT LB state.
I _believe_ that Synology do use the low battery state – it’s certainly in the
configuration files, and I have seen the low battery warning being sent to the
iMac slave.


Is there some way I can test my setup without having to deplete and recharge my
UPS every iteration?    I have tried:
      upsmon –c fsd   (on the master system)
but all that happens is the iMac repeatedly declares ‘Executing automatic
power-fail shutdown’ but does not actually do anything, and nor do any of the
other systems :-(.  Clearly I’ve got something horribly wrong in my
configurations, but being able to simulate on-battery, low-battery etc. from the
UPS would really help the testing/diagnosis!

Thanks again for your help

~Joe

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://alioth-lists.debian.net/pipermail/nut-upsuser/attachments/20190609/09b4790a/attachment.html>

On Jun 9, 2019, at 10:39 AM, Joe Gervasio wrote:
> Is there some way I can test my setup without having to deplete and
recharge my UPS every iteration?    I have tried:
>       upsmon –c fsd   (on the master system)
> but all that happens is the iMac repeatedly declares ‘Executing automatic
power-fail shutdown’ but does not actually do anything, and nor do any of the
other systems :-(.
Hmm, I'm not sure what would make it log the shutdown message repeatedly,
but something occurs to me: you are probably running a recent enough version of
macOS that won't let NUT write to /etc (per upsmon.conf: "POWERDOWNFLAG
/etc/killpower"). I don't remember why we recommend /etc (maybe the
assumption was that /var would get unmounted, but /var is not frequently on a
separate partition on OS X). Maybe /var/run/killpower would be better?
> Clearly I’ve got something horribly wrong in my configurations, but being
able to simulate on-battery, low-battery etc. from the UPS would really help the
testing/diagnosis!
> 
'upsmon -c fsd' should be sufficient to test the shutdown procedure you
are describing, but we also have a driver that reads what is essentially a
NUT/upsc script file: https://networkupstools.org/docs/man/dummy-ups.html
(ignore the parts about repeater mode).

In your case, upsmon is only going to be looking at the "ups.status"
field. You can use the example in the "Implementation" section,
probably with a longer timer value at the last test.

Happy to help - hope we can get this working smoothly. It is one of those things
that should "just work", but some of our assumptions about the OS
don't hold forever.

On Sun, 9 Jun 2019, Joe Gervasio wrote:
> This question undermines my reading of the documentation.  I had thought
that
> these were separate things: 
> 
>     SHUTDOWNCMD "/sbin/shutdown -u -h +1" 
>     NOTIFYCMD /opt/local/sbin/upssched
> 
> I had assumed that the SHUTDOWNCMD would be used by the Nut client (upsmon)
to
> shutdown the slave system,  and that the NOTIFYCMD would be responsible for
> notifying users of what is going on.  
> 
> But I am now inferring from your question, that use of the NOTIFYCMD 
> supersedes or overrides the functionality of the former.  Is that correct?
 So
> if I use a NOTIFYCMD, then I should implement the actual shutdown logic as 
> well as the notification logic in that script, forgetting about
SHUTDOWNCMD?
Using upssched and a upssched-cmd script to shut down the system is an 
alternative to using the builtin upsmon SHUTDOWNCMD on status [OB LB]. A 
upssched-cmd script can provide a managed shutdown well before [OB LB] is 
reached, but should the UPS reach that status upsmon's SHUTDOWNCMD will take
over and enforce an emergency shutdown.

I live in an area with a lot of lightning and frequent power failures, so I have
to be able to perform several managed shutdowns before [LB] is reached.  I do 
this with upssched-cmd. Other sysadmins do not have this problem, and prefer 
something simpler, so they rely solely on builtin upsmon SHUTDOWNCMD.

Your current setup in which upsmon performs the "emergency shutdown"
on status
[OB LB], and upssched + upssched-cmd are used merely to provide useful warnings 
is ok, but you should be clear that this is what you want to do.
> Is there some way I can test my setup without having to deplete and
recharge
> my UPS every iteration?
How about temporarily setting the battery.charge.low to some very high value:

  upsrw -s battery.charge.low=90 -u <user> -p sekret my-UPS

I suggest adding something like the following lines to the top of upssched-cmd 
so that you can include the value of $CHMSG in all your messages.

  STATUS=$( upsc $UPS ups.status )
  CHARGE=$( upsc $UPS battery.charge )
  CHMSG="[$STATUS]:$CHARGE%"

This will give you a clearer idea of what is happening to the UPS unit.

Roger