[Nut-upsuser] debian 8 "jessie" nut 2.7.2 slaves not shutting down

[Roger Price]

On Thu, 19 Oct 2017, Drew Plaster wrote:

> The topology is:
> 	UPS TOPAPC, Data link to master, Power supply to master, slave1 and slave2
> 	UPS MIDAPC, Data link to master, Power supply to master, slave1 and slave2
> 	UPS BOTAPC, Data link to master, Power supply to master, slave1 and slave2
>
> Shutdown plan: When wall power fails for any of the three UPS units, 
> they continue powering the master and the two slaves.  When two of the 
> UPS battery have been depleted and the last (MINSUPPLIES 1) UPS unit 
> reaches the status [OB LB]. the two slaves are shut down, and then the 
> master is shutdown and sends shutdown signal to UPS (#POWERDOWNFLAG 
> /etc/killpower) has been temporarily remarked out in the masters 
> upsmon.conf to test if the slaves would shutdown vai hotsync or 
> deadtime. Anyway, that is how I was envisioning it functioning with the 
> current config files; I may be mis-understanding something but that is 
> the desired shutdown plan.

Drew, it seems to me that your Shutdown plan means living dangerously! 
You have triplicated power backup for maximum system security, yet you let 
it run down until just one UPS is operational, and then only for a short 
time since it is in status [OB LB].

Are the three UPS units fed by the same utility, or by different sources?

Case 1: They share the same utility and they are behaving as one huge UPS 
delivered in three separate boxes.  Assuming they are of the same capacity 
and have the same load, they will run down at the same rate. In this case, 
perhaps it would be better to specify MINSUPPLIES 3 so that the first to 
go [OB LB] drives the shutdown.  Perhaps the slaves will respond correctly 
to this.

Case 2: They have different power sources.  The logic in this case may be 
beyond what is possible with the NUT configuration files.  You may need to 
use additional hardware such as an automatic power transfer switch, and/or 
implement your shutdown logic in a program (sometimes called upssched-cmd) 
called by the upssched.conf CMDSCRIPT directive.  This would mean that the 
upsmon.conf NOTIFYCMD directive would point to upssched, and that 
upssched-cmd would be responsible for sysadmin notifications.

I do not have any direct experience of a logic such as your Shutdown plan 
- perhaps other readers of this list have a deeper insight.

Roger