[Nut-upsuser] 2.2.2-pre2 64 bit rpm tested on openSUSE 10.3

[Roger Price]

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 
really is.

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.

Best Regards,
Roger