[Nut-upsuser] Can this be done with NUT? (ordered shutdown, revisited)
Steffen.Grunewald at aei.mpg.de
Wed Oct 7 08:36:41 UTC 2015
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
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 Grunewald, Cluster Administrator
Max Planck Institute for Gravitational Physics (Albert Einstein Institute)
Am Mühlenberg 1
Fon: +49-331-567 7274
Fax: +49-331-567 7298
More information about the Nut-upsuser