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

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

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