[Nut-upsdev] Bug#441342: Nut can kill power to UPSs that never went on battery

[Arnaud Quette]

tags 441342 upstream
thanks

Hi Robert,

thanks for your report and investigation.
We will check to fix this and give you news back.

2007/9/9, Robert Woodcock <rcw at debian.org>:
> Package: nut
> Version: 2.2.0-2
> Severity: important
>
> I recently set up nut at work to monitor the 15 APC Smart-UPS 1500s we have
> in our server room. Since we currently only have one Linux system, all 15
> UPSs are connected via USB hubs to it.
>
> Over the last couple months, we have had a couple incidents (luckily all on
> weekends) where all 15 UPSs will mysteriously shut off, and we had to
> manually power them back up. To top it off, there was nothing in syslog
> about any UPS going onto battery power and staying there - just a couple
> curious low-battery warnings from one of the UPSs.
>
> This weekend, we tested the UPSs and found that - just our luck - the one
> in particular that fed the Linux system would immediately report low battery
> if you put it in test mode (which it does every two weeks on its own). Nut
> would then immediately shut down the Linux system, and once that was done,
> it would proceed to force a shutdown of all the other UPSs.
>
> The smoking gun is in upsmon's forceshutdown():
>
>         /* set FSD on any "master" UPS entries (forced shutdown in progress) */
>         for (ups = firstups; ups != NULL; ups = ups->next)
>                 if (flag_isset(ups->status, ST_MASTER)) {
>                         isamaster = 1;
>                         setfsd(ups);
>                 }
>
> This code does not attempt to determine whether the UPS in question needs to
> be shut down or not. Shutting down a UPS that is online with a full charge
> is a grievous offense.
>
> To avoid race conditions, I think the proper thing to do is to maintain some
> state information for each UPS as to whether any client is initiating
> shutdown, i.e. has been notified of:
>
> * an on battery condition but then the client disconnected and is therefore
>   unable to receive news that the UPS is back online
>
> * an on battery condition but the master server must disconnect soon
>
> * a low battery or force shutdown condition
>
> If none of these apply, then don't force shutdown the UPS. No good can come
> of it.
>
> A simpler mechanism which could potentially have a race condition, is don't
> shut off any UPS that is online.
>
> Or, at the very least, document the hidden assumption that none of your
> monitored UPS's runtimes will exceed that of your master server's UPS
> runtime in particular.
>
> Thanks!
> --
> Robert Woodcock - rcw at debian.org
> "When you can measure what you are speaking about, and express it in numbers,
> you know something about it; but when you cannot measure it, when you cannot
> express it in numbers, your knowledge is of a meager and unsatisfactory
> kind: it may be the beginning of knowledge, but you have scarcely, in your
> thoughts, advanced to the stage of science."
>         -- William Thomson, Lord Kelvin
>
>

thanks,
Arnaud
-- 
Free Software Developer - http://arnaud.quette.free.fr/
Debian Developer - http://people.debian.org/~aquette/
Network UPS Tools (NUT) Project Leader - http://www.networkupstools.org/
Ubuntu Media Center (UMC) Project Leader - https://launchpad.net/~umc-team