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

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

> On 9 Jun 2019, at 21:19, Roger Price <roger at rogerprice.org> wrote:
> 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.
> 
> <SNIP>
> 
> 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.

Thanks for the clarification.  Yes, this is _exactly_ what I wanted to do

> 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
Thanks for the suggestions.  I’ve successfully done both of these, and see the
message [FSD OB DISCHRG LB] 87% successfully output in a dialog.

> On 9 Jun 2019, at 19:55, Charles Lepple <clepple at gmail.com> wrote:
> 
> 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?

I’ve tried moving the powerdown flag file location to /var/run as you suggest
(although since I run the nut client as root I was not expecting this to be an
issue.  I realise using root is not the best setup, but I don’t want to fall
foul of permissions issues).  Anyway, it makes no difference.

I see the following three broadcast messages in my terminal


UPS ups at xxx.xxx.xxx.xxx: forced shutdown in progress
:
:
Executing automatic power-fail shutdown
:
:
Auto logout and shutdown proceeding  

These are repeated every 15 seconds or so indefinitely, but no shutdown occurs,
and I do not see the messages the actual shutdown command would send, so I
believe this is NOT in fact being executed.   Just to repeat: executing the
shutdown command verbatim as root DOES shut the iMac down, quite aggressively!

The only thing I can see in the system.log that may be relevant is :-
Jun 10 22:06:36 Joes-iMac com.apple.xpc.launchd[1]
(com.apple.xpc.launchd.domain.system): Session adoption is only allowed in user
domains.

This message occurs at the approximate time the shutdown is requested. No idea
what it means, or even if it’s related.


So since this is behaving as expected, but not _functioning_ as expected (!),
later this week I’ll try Roger’s "lightening strike" setup with
upssched-cmd doing the heavy lifting….

Thanks both for your advice;  I’m beginning to lose the will to carry on though,
but I’l have one more stab …  :-)

~Joe



> On 9 Jun 2019, at 21:19, Roger Price <roger at rogerprice.org> wrote:
> 
> 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_______________________________________________
> 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/20190610/f0cbd2df/attachment.html>

On Jun 10, 2019, at 5:50 PM, Joe Gervasio wrote:
> 
> The only thing I can see in the system.log that may be relevant is :-
> Jun 10 22:06:36 Joes-iMac com.apple.xpc.launchd[1]
(com.apple.xpc.launchd.domain.system): Session adoption is only allowed in user
domains.
> 
> This message occurs at the approximate time the shutdown is requested. No
idea what it means, or even if it’s related.
> 
Well, carp. I'm seeing that same message, too. (macOS 10.14.5) It happens
when I run upsmon from launchd, and when the shutdown time arrives.

As a short-term solution, you can start upsmon via sudo, and that should work.
(I got upsmon to launch shutdown, but I killed it before it finished.) I have
not tried logging out after running sudo.

I will poke around and see what other shutdown methods might work from a launchd
context.