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 _______________________________________________ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser