[Nut-upsuser] 2.2.2-pre2 64 bit rpm tested on openSUSE 10.3
rprice at cs.uml.edu
Sun Apr 20 21:02:45 UTC 2008
On Sun, 20 Apr 2008, Arjen de Korte wrote:
> > Hello Arjen, I live in the Alpes Maritimes in the south of France. This
> > is an area with frequent electrical storms, plenty of lightning and it is
> > common to have several short power cuts in succession during a storm. My
> > strategy is to tolerate short power cuts, up to 120 seconds, but if the
> > power cut lasts longer I tell my users, in french not english, that the
> > system is shutting down, and I give them 2 minutes to save their work.
> > My time intervals are short because I want to be able to go through the
> > shutdown-restart sequence several times without having time to recharge
> > the batteries.
> > If I lived say in Paris the strategy would be different since there they
> > have much less lightning.
> > My successive installations of NUT have left me with an accumulation of
> > configuration files which have built up over the years. They could do
> > with a thorough cleanup. I'll have a close look at the upsmon.conf.rpmnew
> > which has appeared.
> The problem with your configuration is, that it isn't robust
I agree with you completely. My defence plan gives me N good cycles but I
am exposed on cycle N+1 because the battery may not have enough charge to
cover the 2 minutes called for by the 'shutdown -h +2' command I use.
> (although you may think it is). When the UPS is reporting a LB
> condition, your setup will not allow shortcuts on the delays and you'd
> still have a two minute delay in the shutdown command. In all
> likelyhood, your UPS will not be able to cope with that when the battery
> is almost empty. Also, after sending the 'shutdown -h +2' command,
> you've effectively lost control over what happens next.
> The better strategy would be to start a upssched timer (I'll call this
> 'powerout') as soon as the power is lost. If the power returns, cancel the
> timer and it is business as usual. When the 'powerout' timer elapses after
> two minutes, you start a second timer (I'll call this one 'delayoff')
> after sending a message through 'wall' to inform the users that a shutdown
> is imminent. Again, if the power returns, you cancel the 'delayoff' timer
> (don't forget an informative 'wall' message) and it is business as usual.
This looks like a good solution not only for cycle N+1, but also for the
first N cycles. It was laziness on my part to pick the "easy" solution,
but it had the advantage of being simple. Even a noobie like myself can
understand it :-)
But what happens on cycle N+2? The ideal strategy should also prevent
the UPS from powering on the machine if its charge fell below x percent,
but I've read in this list that it is not reliable to rely on the UPS's
declared charge - only true coulomb counting could say what the charge
Is it possible to tell a UPS to not send any power to the machine until
it has been charging for say three hours?
> When the 'delayoff' timer elapses, you send the master 'upsmon -c fsd'
> which will (irreversably) start a shutdown sequence. You also send this
> command at any time the UPS reports a low battery condition, whatever the
> state of the timers is. This is the part that is missing in your current
> configuration. You definitly should *not* add delays when the UPS is
> reporting a critical battery, therefor the 2 minute delay in the
> SHUTDOWNCMD is wrong.
Yes, agreed for the cycle N+1. My machines usually have sufficiently
large UPS's, and the claimed backup time for the MGE Ellipse 1500 attached
to the machine on which I am writing this note is 56+ minutes i.e. roughly
N=16. I have never experienced N=4, which is why I willingly choose the
'shutdown -h +2' strategy, despite its clear weakness.
Once I've got nut 2.2.2-pre2 64 bit working smoothly, I'll give some more
thought to this.
More information about the Nut-upsuser