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

[Joe Gervasio]

> 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>