<br><div class="gmail_quote">2012/1/9 William Seligman <span dir="ltr"><<a href="mailto:seligman@nevis.columbia.edu">seligman@nevis.columbia.edu</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On 1/9/12 9:53 AM, Arnaud Quette wrote:<br>
<br>
> 2012/1/6 William Seligman <<a href="mailto:seligman@nevis.columbia.edu">seligman@nevis.columbia.edu</a>><br>
><br>
>> I've googled and RTFM'ed, but still can't solve this one. I hope you folks<br>
>> can.<br>
>><br>
>> This affects my entire computer cluster, but let's start simple: I've got<br>
>> a computer running NUT; OS is Scientific Linux 5.5; kernel<br>
>> 2.6.18-274.12.1.el5xen. It connects to an APC SMART-UPS via an APC<br>
>> SmartCard using the snmp-ups driver. It generally works: upsmon will detect<br>
>> if the battery is low (I get an e-mail message); I can control the UPS,<br>
>> inspect it variables, set variables, issue commands, and so on.<br>
><br>
> If "On battery" and "Low battery" are both detected, there should be no<br>
> issue.<br>
><br>
>> There's just one thing that does not happen: when the UPS goes critical,<br>
>> the computer does not shut down. The upsmon daemon does not display any<br>
>> messages, does not write to the syslog, does not send e-mail, etc.; even<br>
>> though I've configured it to do so in upsmon.conf.>><br>
>> I've tried nut-2.2.2, nut-2.4.3, and nut-2.6.2, and the symptom is the<br>
>> same.<br>
><br>
> Using the latest version, when possible, is always a good idea.<br>
<br>
</div>Installing nut-2.6.2 on a Scientific Linux 5.5 system was a bit difficult, and<br>
played havoc with my regular yum updates. After I've finished debugging this<br>
problem, I'm going to completely reinstall the OS to make sure I've got a<br>
consistent set of RPMs.<br></blockquote><div><br>you may have prefered to rebuild an SRPM like that:<br><a href="http://zid-luxinst.uibk.ac.at/linux/rpm2html/fedora/14/i386/updates/nut-2.6.2-1.fc14.i686.html">http://zid-luxinst.uibk.ac.at/linux/rpm2html/fedora/14/i386/updates/nut-2.6.2-1.fc14.i686.html</a><br>
 </div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div class="h5">
>> I tried issuing a "graceful reboot" command via the APC SmartCard's web and<br>
>> telnet interface. It made no difference; the system still did not shut<br>
>> down.<br>
>><br>
>> Now let's extend the problem to my cluster: I have a variety of different<br>
>> computers, all running Scientific Linux 5.5, connecting through different<br>
>> switches, connecting to different flavors of APC SMART-UPSes, via<br>
>> SmartCards, each ranging in age from six months to five years. They all<br>
>> exhibit this same symptom, as I painfully discovered during a recent power<br>
>> outage: they all sent me e-mail when the UPSes went to low battery, but<br>
>> none turned off when the UPS went critical. Given the range of hardware<br>
>> involved, this must be a common software problem.<br>
>><br>
>> The systems will shut down properly if I do "upsmon -c fsd", so it doesn't<br>
>> appear to be a permissions problem.<br>
>><br>
>> I don't think this is the upsdrv_shutdown() issue described in the snmp-ups<br>
>> man page; I do not care if the UPS shuts down when the computer does, nor<br>
>> do I want it to. I just want upsmon to shut down the system when the UPS<br>
>> goes critical.<br>
>><br>
>> Here are my config files; the system is tanya, its UPS is tanya-ups. Any<br>
>> advice?<br>
>><br>
>> ups.conf:<br>
>><br>
>> [tanya-ups]<br>
>>        driver = snmp-ups<br>
>>        port = tanya-ups<br>
>>        community = private<br>
>>        mibs = apcc<br>
>><br>
>> upsd.conf:<br>
>><br>
>> # LISTEN 0.0.0.0 3493<br>
>><br>
>> upsd.users:<br>
>><br>
>> [admin]<br>
>>        password = nowayjose<br>
>>        actions = SET<br>
>>        instcmds = all<br>
>>        upsmon master<br>
>><br>
><br>
> it's also a good idea to separate monitoring and administrative users.<br>
> Ie:<br>
> [admin]<br>
>        password = XXX<br>
>        actions = SET<br>
>        instcmds = all<br>
><br>
> [monuser]<br>
>        password = XXX<br>
>        upsmon master<br>
><br>
>> upsmon.conf:<br>
>><br>
>> MONITOR tanya-ups@localhost 1 admin nowayjose master<br>
>> MINSUPPLIES 1<br>
>> SHUTDOWNCMD "/sbin/shutdown -h +0"<br>
>> NOTIFYCMD /home/bin/notify.sh # sends me e-mail<br>
>> POLLFREQ 5<br>
>> POLLFREQALERT 5<br>
>> HOSTSYNC 15<br>
>> DEADTIME 15<br>
>> POWERDOWNFLAG /etc/killpower<br>
>> NOTIFYFLAG ONLINE       SYSLOG<br>
>> NOTIFYFLAG ONBATT       SYSLOG+WALL<br>
>> NOTIFYFLAG LOWBATT      SYSLOG+WALL<br>
>> NOTIFYFLAG FSD          SYSLOG+WALL+EXEC<br>
>> NOTIFYFLAG COMMOK       SYSLOG<br>
>> NOTIFYFLAG COMMBAD      SYSLOG<br>
>> NOTIFYFLAG SHUTDOWN     SYSLOG+WALL+EXEC<br>
>> NOTIFYFLAG REPLBATT     SYSLOG+WALL+EXEC<br>
>> NOTIFYFLAG NOCOMM       SYSLOG<br>
>> NOTIFYFLAG NOPARENT     SYSLOG+WALL<br>
>> RBWARNTIME 43200<br>
>> NOCOMMWARNTIME 300<br>
>> FINALDELAY 5<br>
><br>
> Your config seems fine.<br>
> An interesting test to do would be to stop upsmon, but keep snmp-ups and<br>
> upsd, then discharge your UPS and to ensure that you indeed get an<br>
> ups.status == "OB LB", which triggers the call to upsmon.conf->SHUTDOWNCMD.<br>
> Note that you need both "OB" and "LB", since you may have "low battery" and<br>
> be "online" at the same time!<br>
<br>
</div></div>This is a good idea, and I ran the test. I disconnected the UPS, and<br>
periodically checked the output of:<br>
<br>
upsc tanya-ups@localhost ups.status<br>
<br>
Eventually this command returned "OB LB" as you said. But upsmon did nothing. I<br>
waited and eventually the UPS shut power to the system in a hard crash.<br></blockquote><div><br>ooch, mea culpa!<br>I was too brief in my answer, and forgot to tell you the obvious: remove your computer from the UPS, in order to avoid such crash.<br>
 </div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
So the UPS is sending the correct signals, and snmp-ups is reporting the correct<br>
status. Is there anything else I can check to trace the cause of the problem?<br></blockquote></div><br>indeed, though there is an issue, as you've reported initially.<br clear="all"><br>Could you do this test again, but this time:<br>
- remove your server from the UPS,<br>- start upsmon in debug mode. If it's already started, just call "upsmon -c stop ; upsmon -DDDDD"<br>and send us back the output, at least when it should see the "OB LB" condition, to see what's going on.<br>
<br>cheers,<br>Arnaud<br>-- <br>Linux / Unix Expert R&D - Eaton - <a href="http://powerquality.eaton.com" target="_blank">http://powerquality.eaton.com</a><br>Network UPS Tools (NUT) Project Leader - <a href="http://www.networkupstools.org/" target="_blank">http://www.networkupstools.org/</a><br>
Debian Developer - <a href="http://www.debian.org" target="_blank">http://www.debian.org</a><br>Free Software Developer - <a href="http://arnaud.quette.free.fr/" target="_blank">http://arnaud.quette.free.fr/</a><br><br>