[Nut-upsuser] Can this be done with NUT? (ordered shutdown, revisited)

[Steffen Grunewald]

Hi Charles, all:

On Tue, Oct 06, 2015 at 08:45:40AM -0400, Charles Lepple wrote:
> On Oct 6, 2015, at 5:40 AM, Steffen Grunewald <Steffen.Grunewald at aei.mpg.de> wrote:
> > 
> > What I currently tried:
> > - I found a longish discussion on this list, dating back to six years
> >  ago: http://lists.alioth.debian.org/pipermail/nut-upsuser/2009-February/004772.html
> >  In particular, Marco's requirements look quite similar to ours, but
> >  there was apparently no solution (back then). I mayhave missed a later
> >  continuation though.
> 
> Right, I don't think the "ignorelb" flag was added to drivers until 2011.

And somehow this option is named in a way that made my input filter drop it
quite early. 
Yes, indeed, this one does the trick.
I still don't understand where exactly it happens :/ (but I don't care much)

> > - Use multiple drivers, with override.battery.charge.low set to various
> >  levels - or "dummy-ups" repeaters with the same modification
> > - Let client groups upsmon-read one of those "virtual" UPSes
> > 
> > What I found:
> > - upsd obviously doesn't calculate LB itself (even if charge.low is set
> >  to 105.00 for testing purposes). Does this only happen on OB, or does
> >  upsd do no calculations at all?
> >  Apparently, ordered handling of multiple shutdown conditions cannot be
> >  done this way?
> 
> Also correct that upsd does not calculate LB, but the drivers can do what you are describing if the "ignorelb" flag is set. Using dummy-ups in repeater mode does sound like a good option.

It is ;)

What I am doing now:

- have a (primary) snmp-ups driver with override.battery.charge.low = 50 *and*
  ignorelb = true (is this correct syntax?), as 50% is the critical capacity
  where I cannot trust the UPS anymore (for more than a few minutes).
  battery.runtime returns random numbers, batttery.runtime.low is 0, and I
  don't have a better guess either :/

- a bunch of dummy-ups drivers, each with a different charge.low setting (55,
  60, 70, 85, 105 [!]), and ignorelb set.

> Another potential hitch: while you can override LB, I haven't looked into overriding OB. So for testing, it might be necessary to have a copy of dummy ups reading from a file, in place of the actual snmp-ups driver.

This is easy: just insert a "override.battery.charge = 66.66" into the primary
driver definition while testing - which can be done with
  upsc -l | xargs -t -i% upsc %$localhost ups.status
When done with testing, "upsdrvctl stop primary", remove the override from ups.conf
and "upsdrvctl start primary". 

Yes, you'll get "OL LB" reports. Don't know what an upsmon would do with that :)
(Workaround: Next to override.battery.charge, define override.ups.status?)


There's only one drawback caused by the repeater logic set up this way:

- upsdrvctl will start the primary (real) driver since it can connect via snmp

- upsdrvctl fails (Connection refused) connecting to the repeaters since upsd
  isn't running yet

- upsd will only see the primary driver (can't connect to ... dummy-ups) 
  but then provide a path for the repeaters which will be started by a second
  invocation of "upsdrvctl start"

- everything is fine after that

Just using "/etc/init.d/nut-server start" will fail: it will fire up the
primary driver and upsd, but not the repeaters. I presume a "upsdrvctl start"
(in /etc/rc.local?) will handle this. (OS is Debian Wheezy.)

This is fine with me as "repeaters" were probably invented to be run on a
machine different from the one running the primary driver(s), and therefore
connecting to an already running upsd is the "typical use case".

Thanks a lot, Charles, you saved my week!

Steffen

-- 
Steffen Grunewald, Cluster Administrator
Max Planck Institute for Gravitational Physics (Albert Einstein Institute)
Am Mühlenberg 1
D-14476 Potsdam-Golm
Germany
~~~
Fon: +49-331-567 7274
Fax: +49-331-567 7298
Mail: steffen.grunewald(at)aei.mpg.de
~~~