<tt><font size=2>> Do you have this in nagios.cfg?<br>
> retain_state_information=1<br>
</font></tt>
<br><tt><font size=2>yes, i do have that set</font></tt>
<br>
<br>
<br>
<br>
<br><font size=1 color=#5f5f5f face="sans-serif">From:      
 </font><font size=1 face="sans-serif">nagios-users-request@lists.sourceforge.net</font>
<br><font size=1 color=#5f5f5f face="sans-serif">To:      
 </font><font size=1 face="sans-serif">nagios-users@lists.sourceforge.net,
</font>
<br><font size=1 color=#5f5f5f face="sans-serif">Date:      
 </font><font size=1 face="sans-serif">06/18/2013 01:56 PM</font>
<br><font size=1 color=#5f5f5f face="sans-serif">Subject:    
   </font><font size=1 face="sans-serif">Nagios-users
Digest, Vol 85, Issue 6</font>
<br>
<hr noshade>
<br>
<br>
<br><tt><font size=2>Send Nagios-users mailing list submissions to<br>
                
nagios-users@lists.sourceforge.net<br>
<br>
To subscribe or unsubscribe via the World Wide Web, visit<br>
                
</font></tt><a href="https://lists.sourceforge.net/lists/listinfo/nagios-users"><tt><font size=2>https://lists.sourceforge.net/lists/listinfo/nagios-users</font></tt></a><tt><font size=2><br>
or, via email, send a message with subject or body 'help' to<br>
                
nagios-users-request@lists.sourceforge.net<br>
<br>
You can reach the person managing the list at<br>
                
nagios-users-owner@lists.sourceforge.net<br>
<br>
When replying, please edit your Subject line so it is more specific<br>
than "Re: Contents of Nagios-users digest..."<br>
<br>
<br>
Today's Topics:<br>
<br>
   1. reload appears to cause force of DOWN; SOFT;      
          x to DOWN; HARD;<br>
      1 (Sean McKell)<br>
   2. Re: reload appears to cause force of DOWN; SOFT; x to DOWN;<br>
      HARD; 1 (Travis Runyard)<br>
   3. Re: Issues with NEB modules breaking after restart<br>
      (Andrew Widdersheim)<br>
   4. Functions to do Availibility in reporting (omar saddiki)<br>
   5. Fwd: Functions to do Availibility in reporting (omar saddiki)<br>
   6. Wmi (martin Rodriguez)<br>
   7. Re: Wmi (Sunil Sankar)<br>
   8. check_ntp_time offset unknown (Bennett, Jan)<br>
   9. Re: check_ntp_time offset unknown (Holger Wei?)<br>
  10. Re: check_ntp_time offset unknown (Giles Coochey)<br>
  11. Problem with check_openmanage plugin and storage (Nic Bernstein)<br>
<br>
<br>
----------------------------------------------------------------------<br>
<br>
Message: 1<br>
Date: Thu, 13 Jun 2013 17:31:44 -0600<br>
From: Sean McKell <mckell@us.ibm.com><br>
Subject: [Nagios-users] reload appears to cause force of DOWN; SOFT;  
              x<br>
                
to DOWN; HARD; 1<br>
To: nagios-users@lists.sourceforge.net<br>
Message-ID:<br>
                
<OF17CEA331.79DB0522-ON87257B89.0080C0E1-87257B89.0081405C@us.ibm.com><br>
Content-Type: text/plain; charset="us-ascii"<br>
<br>
Running 3.4.1:<br>
I see this strange anomaly, where a host check is in the middle of doing
<br>
retries before hitting max_attempts, but after a server reload occurs,
the <br>
next check is automatically forced to DOWN;HARD;1, as seen here:<br>
<br>
[2013-06-04 08:40:21] HOST ALERT: 5gt4;DOWN;SOFT;1;CRITICAL: Connection
<br>
timed out to '' after 160 seconds (user 'chk'). Expected prompt not found.
<br>
Last output was ''.<br>
[2013-06-04 08:47:18] HOST ALERT: 5gt4;DOWN;SOFT;2;CRITICAL: Connection
<br>
timed out to '' after 160 seconds (user 'chk'). Expected prompt not found.
<br>
Last output was ''.<br>
[2013-06-04 08:54:03] HOST ALERT: 5gt4;DOWN;SOFT;3;CRITICAL: Connection
<br>
timed out to '' after 160 seconds (user 'chk'). Expected prompt not found.
<br>
Last output was ''.<br>
(reload happens here)<br>
[2013-06-04 09:00:52] HOST ALERT: 5gt4;DOWN;HARD;1;CRITICAL: Connection
<br>
timed out to '' after 160 seconds (user 'chk'). Expected prompt not found.
<br>
Last output was ''.<br>
<br>
Why is it skipping the rest of the attempts and going straight to <br>
DOWN;HARD after the reload ?<br>
Seems like a bug to me.<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
<br>
------------------------------<br>
<br>
Message: 2<br>
Date: Thu, 13 Jun 2013 21:39:48 -0700<br>
From: Travis Runyard <travisrunyard@gmail.com><br>
Subject: Re: [Nagios-users] reload appears to cause force of DOWN;<br>
                
SOFT; x to DOWN; HARD; 1<br>
To: Nagios Users List <nagios-users@lists.sourceforge.net><br>
Message-ID:<br>
                
<CANCZ1yG6CYiE2GYL3j5W3Gj9WjrTz4SmGONnaZUxbL5piUB=zA@mail.gmail.com><br>
Content-Type: text/plain; charset="iso-8859-1"<br>
<br>
Do you have this in nagios.cfg?<br>
retain_state_information=1<br>
<br>
<br>
On Thu, Jun 13, 2013 at 4:31 PM, Sean McKell <mckell@us.ibm.com>
wrote:<br>
<br>
> Running 3.4.1:<br>
> I see this strange anomaly, where a host check is in the middle of
doing<br>
> retries before hitting max_attempts, but after a server reload occurs,
the<br>
> next check is automatically forced to DOWN;HARD;1, as seen here:<br>
><br>
> [2013-06-04 08:40:21] HOST ALERT: 5gt4;DOWN;SOFT;1;CRITICAL: Connection<br>
> timed out to '' after 160 seconds (user 'chk'). Expected prompt not
found.<br>
> Last output was ''.<br>
> [2013-06-04 08:47:18] HOST ALERT: 5gt4;DOWN;SOFT;2;CRITICAL: Connection<br>
> timed out to '' after 160 seconds (user 'chk'). Expected prompt not
found.<br>
> Last output was ''.<br>
> [2013-06-04 08:54:03] HOST ALERT: 5gt4;DOWN;SOFT;3;CRITICAL: Connection<br>
> timed out to '' after 160 seconds (user 'chk'). Expected prompt not
found.<br>
> Last output was ''.<br>
> (reload happens here)<br>
> [2013-06-04 09:00:52] HOST ALERT: 5gt4;DOWN;HARD;1;CRITICAL: Connection<br>
> timed out to '' after 160 seconds (user 'chk'). Expected prompt not
found.<br>
> Last output was ''.<br>
><br>
> Why is it skipping the rest of the attempts and going straight to<br>
> DOWN;HARD after the reload ?<br>
> Seems like a bug to me.<br>
><br>
><br>
> ------------------------------------------------------------------------------<br>
> This SF.net email is sponsored by Windows:<br>
><br>
> Build for Windows Store.<br>
><br>
> </font></tt><a href="http://p.sf.net/sfu/windows-dev2dev"><tt><font size=2>http://p.sf.net/sfu/windows-dev2dev</font></tt></a><tt><font size=2><br>
> _______________________________________________<br>
> Nagios-users mailing list<br>
> Nagios-users@lists.sourceforge.net<br>
> </font></tt><a href="https://lists.sourceforge.net/lists/listinfo/nagios-users"><tt><font size=2>https://lists.sourceforge.net/lists/listinfo/nagios-users</font></tt></a><tt><font size=2><br>
> ::: Please include Nagios version, plugin version (-v) and OS when<br>
> reporting any issue.<br>
> ::: Messages without supporting info will risk being sent to /dev/null<br>
><br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
<br>
------------------------------<br>
<br>
Message: 3<br>
Date: Fri, 14 Jun 2013 13:03:56 -0400<br>
From: Andrew Widdersheim <awiddersheim@hotmail.com><br>
Subject: Re: [Nagios-users] Issues with NEB modules breaking after<br>
                
restart<br>
To: "nagios-users@lists.sourceforge.net"<br>
                
<nagios-users@lists.sourceforge.net><br>
Message-ID: <SNT143-W535DE68DF8CC060F587EF0DD800@phx.gbl><br>
Content-Type: text/plain; charset="iso-8859-1"<br>
<br>
<div>To answer my own question... I'm pretty sure two nagios instances
were spawned at once. The nagios init script that comes with nagios-core
is the best at handling this situation.</div><br>
                  
               
                 
                 
               
     <br>
<br>
<br>
------------------------------<br>
<br>
Message: 4<br>
Date: Mon, 17 Jun 2013 15:21:37 +0000<br>
From: omar saddiki <omar.saddiki@gmail.com><br>
Subject: [Nagios-users] Functions to do Availibility in reporting<br>
To: Nagios Users List <nagios-users@lists.sourceforge.net><br>
Message-ID:<br>
                
<CAN5T1CHYs_w4t0=muvDosc+KsjsLf5yW305X3-K1ZrkVtPNGgQ@mail.gmail.com><br>
Content-Type: text/plain; charset="iso-8859-1"<br>
<br>
Hi,<br>
<br>
Please, someone can give me the function used by Nagios in reporting onglet<br>
to extract the availibility between two times.<br>
<br>
Regards<br>
 SADDIKI<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
<br>
------------------------------<br>
<br>
Message: 5<br>
Date: Mon, 17 Jun 2013 15:42:17 +0000<br>
From: omar saddiki <omar.saddiki@gmail.com><br>
Subject: [Nagios-users] Fwd: Functions to do Availibility in reporting<br>
To: Nagios Users List <nagios-users@lists.sourceforge.net><br>
Message-ID:<br>
                
<CAN5T1CHOYvGnu8Z8Q_bbrtJe8A7=phdCNErWmN9cAjX59eU8wA@mail.gmail.com><br>
Content-Type: text/plain; charset="iso-8859-1"<br>
<br>
Hi,<br>
<br>
Please, someone can give me the function used by Nagios in reporting onglet<br>
to extract the availibility between two times.<br>
<br>
Regards<br>
 SADDIKI<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
<br>
------------------------------<br>
<br>
Message: 6<br>
Date: Mon, 17 Jun 2013 15:14:24 -0300<br>
From: martin Rodriguez <maestin@gmail.com><br>
Subject: [Nagios-users] Wmi<br>
To: nagios-users@lists.sourceforge.net<br>
Message-ID:<br>
                
<CACrJBAsbWM8wVuPasjJQp0VumJZw5aj_qN6DGS+OHeZTMfmEXg@mail.gmail.com><br>
Content-Type: text/plain; charset="iso-8859-1"<br>
<br>
Hi I am installing Nagios 3.4.3 on ubuntu and I can not configure the<br>
plugin check_wmi_plus.conf someone had expereince in this topic<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
<br>
------------------------------<br>
<br>
Message: 7<br>
Date: Tue, 18 Jun 2013 00:14:07 +0530<br>
From: Sunil Sankar <sunil@sunil.cc><br>
Subject: Re: [Nagios-users] Wmi<br>
To: Nagios Users List <nagios-users@lists.sourceforge.net><br>
Message-ID:<br>
                
<CAPqUM3W+mo5bRRoi6dxAwSdLPs87poqqQZHiJdQWVDh-7c5QhA@mail.gmail.com><br>
Content-Type: text/plain; charset="iso-8859-1"<br>
<br>
What is the error you are getting<br>
<br>
<br>
On Mon, Jun 17, 2013 at 11:44 PM, martin Rodriguez <maestin@gmail.com>wrote:<br>
<br>
> Hi I am installing Nagios 3.4.3 on ubuntu and I can not configure
the<br>
> plugin check_wmi_plus.conf someone had expereince in this topic<br>
><br>
><br>
> ------------------------------------------------------------------------------<br>
> This SF.net email is sponsored by Windows:<br>
><br>
> Build for Windows Store.<br>
><br>
> </font></tt><a href="http://p.sf.net/sfu/windows-dev2dev"><tt><font size=2>http://p.sf.net/sfu/windows-dev2dev</font></tt></a><tt><font size=2><br>
> _______________________________________________<br>
> Nagios-users mailing list<br>
> Nagios-users@lists.sourceforge.net<br>
> </font></tt><a href="https://lists.sourceforge.net/lists/listinfo/nagios-users"><tt><font size=2>https://lists.sourceforge.net/lists/listinfo/nagios-users</font></tt></a><tt><font size=2><br>
> ::: Please include Nagios version, plugin version (-v) and OS when<br>
> reporting any issue.<br>
> ::: Messages without supporting info will risk being sent to /dev/null<br>
><br>
<br>
<br>
<br>
-- <br>
Regards<br>
Sunil Sankar<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
<br>
------------------------------<br>
<br>
Message: 8<br>
Date: Fri, 14 Jun 2013 14:10:43 +0000<br>
From: "Bennett, Jan" <JBennett@ntta.org><br>
Subject: [Nagios-users] check_ntp_time offset unknown<br>
To: "'nagios-users@lists.sourceforge.net'"<br>
                
<nagios-users@lists.sourceforge.net><br>
Message-ID:<br>
                
<E11B0F59D3334D469B36FCA07490BA8C186E67EF@NTTAEXMB01.ntta.local><br>
Content-Type: text/plain; charset="us-ascii"<br>
<br>
We have implemented a NTP sync check in all of the NRDS checks that we
are rolling out right now but I've run into a bit of a snag.<br>
<br>
I am getting returns of 'Offset Unknown' on all clients.  It appears
to only happen for a short period of time (30 min or so) and then it will
clear its self up for a bit but the issue will always return.<br>
<br>
>From the client that is reporting the unknown offset, I can run the
following:<br>
<br>
# ./check_ntp_time -H localhost<br>
NTP CRITICAL: Offset unknown|<br>
# ./check_ntp_time -V<br>
check_ntp_time v1.4.16 (nagios-plugins 1.4.16)<br>
# ntpdc -p<br>
     remote           local    
 st poll reach  delay   offset    disp<br>
=======================================================================<br>
=LOCAL(0)        127.0.0.1       10
  64   17 0.00000  0.000000 0.96858<br>
*timeserver1     xxx.xxx.xxx.xxx    2   64  
17 0.00098  4.956048 0.00580<br>
# /usr/local/nagios/libexec/check_ntp_time -v -H localhost<br>
sending request to peer 0<br>
response from peer 0: offset -2.777669579e-07<br>
sending request to peer 0<br>
response from peer 0: offset -2.161832526e-07<br>
sending request to peer 0<br>
response from peer 0: offset -4.009343684e-07<br>
sending request to peer 0<br>
response from peer 0: offset -1.987209544e-07<br>
discarding peer 0: stratum=0<br>
overall average offset: 0<br>
NTP CRITICAL: Offset unknown|<br>
<br>
In my searches, I noticed a number of people reporting the same issue with
the supposed solution being to update your Nagios plugins to 1.4.13.  I
have done so and am now running 1.4.16 without any change in the service
check.<br>
<br>
Also, I am unable to check a remote NTP server from these clients as they
do not have access to the outside world.<br>
<br>
It has been suggested that the stratum=0 may be the culprit, but I'm not
sure of my options here.<br>
<br>
Any help would be greatly appreciated.<br>
<br>
Jan<br>
<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
<br>
------------------------------<br>
<br>
Message: 9<br>
Date: Tue, 18 Jun 2013 17:24:50 +0200<br>
From: Holger Wei? <holger@cis.fu-berlin.de><br>
Subject: Re: [Nagios-users] check_ntp_time offset unknown<br>
To: Nagios Users <nagios-users@lists.sourceforge.net><br>
Message-ID: <20130618152450.GA678632@zedat.fu-berlin.de><br>
Content-Type: text/plain; charset=iso-8859-1<br>
<br>
* Bennett, Jan <JBennett@ntta.org> [2013-06-14 14:10]:<br>
> # ./check_ntp_time -H localhost<br>
> NTP CRITICAL: Offset unknown|<br>
<br>
Could you please run "ntpq -c rv" when this happens and post
the output?<br>
<br>
> It has been suggested that the stratum=0 may be the culprit, but I'm
not sure of my options here.<br>
<br>
Yes, stratum=0 is the culprit.  An NTP server wouldn't usually report<br>
such a stratum value.<br>
<br>
Holger<br>
<br>
-- <br>
Holger Wei?               | Freie Universit?t
Berlin<br>
holger@zedat.fu-berlin.de | Zentraleinrichtung f?r Datenverarbeitung (ZEDAT)<br>
Telefon: +49 30 838-55949 | Fabeckstra?e 32, 14195 Berlin (Germany)<br>
Telefax: +49 30 838455949 | </font></tt><a href="https://www.zedat.fu-berlin.de/"><tt><font size=2>https://www.zedat.fu-berlin.de/</font></tt></a><tt><font size=2><br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 10<br>
Date: Tue, 18 Jun 2013 16:35:03 +0100<br>
From: Giles Coochey <giles@coochey.net><br>
Subject: Re: [Nagios-users] check_ntp_time offset unknown<br>
To: nagios-users@lists.sourceforge.net<br>
Message-ID: <51C07E27.7000400@coochey.net><br>
Content-Type: text/plain; charset="iso-8859-1"<br>
<br>
On 14/06/2013 15:10, Bennett, Jan wrote:<br>
><br>
> We have implemented a NTP sync check in all of the NRDS checks that
we <br>
> are rolling out right now but I've run into a bit of a snag.<br>
><br>
> I am getting returns of 'Offset Unknown' on all clients.  It
appears <br>
> to only happen for a short period of time (30 min or so) and then
it <br>
> will clear its self up for a bit but the issue will always return.<br>
><br>
> From the client that is reporting the unknown offset, I can run the
<br>
> following:<br>
><br>
> # ./check_ntp_time -H localhost<br>
> NTP CRITICAL: Offset unknown|<br>
> # ./check_ntp_time -V<br>
> check_ntp_time v1.4.16 (nagios-plugins 1.4.16)<br>
> # ntpdc -p<br>
>      remote           local
    st poll reach  delay   offset    disp<br>
> =======================================================================<br>
> =LOCAL(0)        127.0.0.1    10  
64   17 0.00000  0.000000 0.96858<br>
> *timeserver1  xxx.xxx.xxx.xxx    2   64  
17 0.00098  4.956048 0.00580<br>
><br>
> # /usr/local/nagios/libexec/check_ntp_time -v -H localhost<br>
> sending request to peer 0<br>
> response from peer 0: offset -2.777669579e-07<br>
> sending request to peer 0<br>
> response from peer 0: offset -2.161832526e-07<br>
> sending request to peer 0<br>
> response from peer 0: offset -4.009343684e-07<br>
> sending request to peer 0<br>
> response from peer 0: offset -1.987209544e-07<br>
> discarding peer 0: stratum=0<br>
> overall average offset: 0<br>
> NTP CRITICAL: Offset unknown|<br>
><br>
> In my searches, I noticed a number of people reporting the same issue
<br>
> with the supposed solution being to update your Nagios plugins to
<br>
> 1.4.13.  I have done so and am now running 1.4.16 without any
change <br>
> in the service check.<br>
><br>
> Also, I am unable to check a remote NTP server from these clients
as <br>
> they do not have access to the outside world.<br>
><br>
> It has been suggested that the stratum=0 may be the culprit, but I'm
<br>
> not sure of my options here.<br>
><br>
> Any help would be greatly appreciated.<br>
><br>
><br>
I get this shortly after a NTP client has booted up. Once NTP has been
<br>
running for a while it goes away.<br>
<br>
-- <br>
Regards,<br>
<br>
Giles Coochey, CCNP, CCNA, CCNAS<br>
NetSecSpec Ltd<br>
+44 (0) 7983 877438<br>
</font></tt><a href=http://www.coochey.net/><tt><font size=2>http://www.coochey.net</font></tt></a><tt><font size=2><br>
</font></tt><a href=http://www.netsecspec.co.uk/><tt><font size=2>http://www.netsecspec.co.uk</font></tt></a><tt><font size=2><br>
giles@coochey.net<br>
<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
-------------- next part --------------<br>
A non-text attachment was scrubbed...<br>
Name: smime.p7s<br>
Type: application/pkcs7-signature<br>
Size: 4968 bytes<br>
Desc: S/MIME Cryptographic Signature<br>
<br>
------------------------------<br>
<br>
Message: 11<br>
Date: Tue, 18 Jun 2013 11:03:32 -0500<br>
From: Nic Bernstein <nic@onlight.com><br>
Subject: [Nagios-users] Problem with check_openmanage plugin and<br>
                
storage<br>
To: nagios-users@lists.sourceforge.net<br>
Message-ID: <51C084D4.8020104@onlight.com><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
We've recently been experimenting with Trond Hasle Amundsen's<br>
check_openmanage on a large network with about a hundred Dell servers of<br>
various ages, capabilities, etc.  Mostly PE-2950, R210, R410 and R720.
<br>
Much thanks to Trond for all his great work on Nagios plugins and other<br>
projects, by the way.<br>
<br>
We've hit a wall, however, with the storage monitoring aspects of this<br>
plugin.<br>
<br>
For example, here's a quite specific case.  This is a new PE R720,
in debug:<br>
<br>
    onlight@monitor:~$ check_openmanage -H host -C secret -d<br>
       System:      PowerEdge R720  
        OMSA version:    7.1.0<br>
       ServiceTag:  #######        
         Plugin version:  3.7.9<br>
       BIOS/date:   1.2.6 05/10/2012    
    Checking mode:   SNMPv2c UDP/IPv4<br>
    -----------------------------------------------------------------------------<br>
       Storage Components          
                     
                     
 <br>
    =============================================================================<br>
      STATE  |    ID    |  MESSAGE
TEXT                    
                     <br>
    ---------+----------+--------------------------------------------------------<br>
          OK |        0 |
Controller 0 [PERC H310 Mini] is Ready<br>
     WARNING |  0:0:1:0 | Physical Disk 0:1:0 [Ata ST2000DM001-9YN164,
2.0TB] on ctrl 0 is Online, Not Certified<br>
     WARNING |  0:0:1:1 | Physical Disk 0:1:1 [Ata ST2000DM001-9YN164,
2.0TB] on ctrl 0 is Online, Not Certified<br>
          OK |      0:0 | Logical
Drive '/dev/sda' [RAID-1, 1862.50 GB] is Ready<br>
          OK |      0:0 | Connector
0 [SAS] on controller 0 is Ready<br>
          OK |      0:1 | Connector
1 [SAS] on controller 0 is Ready<br>
          OK |    0:0:1 | Enclosure
0:0:1 [Backplane] on controller 0 is Ready<br>
    -----------------------------------------------------------------------------<br>
       Chassis Components          
                     
                     
 <br>
    =============================================================================<br>
      STATE  |  ID  |  MESSAGE TEXT
                     
                     
 <br>
    ---------+------+------------------------------------------------------------<br>
          OK |    0 | Memory module
0 [DIMM_A1, 4096 MB] is Ok<br>
          OK |    1 | Memory module
1 [DIMM_A2, 4096 MB] is Ok<br>
          OK |    2 | Memory module
2 [DIMM_A3, 4096 MB] is Ok<br>
          OK |    3 | Memory module
3 [DIMM_A4, 4096 MB] is Ok<br>
          OK |    0 | Chassis fan 0
[System Board Fan1 RPM] reading: 1200 RPM<br>
          OK |    1 | Chassis fan 1
[System Board Fan2 RPM] reading: 1080 RPM<br>
          OK |    2 | Chassis fan 2
[System Board Fan3 RPM] reading: 1200 RPM<br>
          OK |    3 | Chassis fan 3
[System Board Fan4 RPM] reading: 1080 RPM<br>
          OK |    4 | Chassis fan 4
[System Board Fan5 RPM] reading: 1080 RPM<br>
          OK |    5 | Chassis fan 5
[System Board Fan6 RPM] reading: 1080 RPM<br>
          OK |    0 | Power Supply 0
[AC]: Presence detected<br>
          OK |    0 | Temperature Probe
0 [System Board Inlet Temp] reads 26 C (min=3/-7, max=42/47)<br>
          OK |    1 | Temperature Probe
1 [System Board Exhaust Temp] reads 33 C (min=8/3, max=70/75)<br>
          OK |    2 | Temperature Probe
2 [CPU1 Temp] reads 49 C (min=8/3, max=83/88)<br>
          OK |    0 | Processor 0 [Intel
Xeon E5-2603 0 1.80GHz] is Present<br>
          OK |    0 | Voltage sensor
0 [CPU1 VCORE PG] is Good<br>
          OK |    1 | Voltage sensor
1 [System Board 3.3V PG] is Good<br>
          OK |    2 | Voltage sensor
2 [System Board 5V PG] is Good<br>
          OK |    3 | Voltage sensor
3 [CPU1 PLL PG] is Good<br>
          OK |    4 | Voltage sensor
4 [System Board 1.1V PG] is Good<br>
          OK |    5 | Voltage sensor
5 [CPU1 M23 VDDQ PG] is Good<br>
          OK |    6 | Voltage sensor
6 [CPU1 M23 VTT PG] is Good<br>
          OK |    7 | Voltage sensor
7 [System Board FETDRV PG] is Good<br>
          OK |    8 | Voltage sensor
8 [CPU1 VSA PG] is Good<br>
          OK |    9 | Voltage sensor
9 [CPU1 M01 VDDQ PG] is Good<br>
          OK |   10 | Voltage sensor 10 [System
Board NDC PG] is Good<br>
          OK |   11 | Voltage sensor 11 [CPU1
VTT PG] is Good<br>
          OK |   12 | Voltage sensor 12 [System
Board 1.5V PG] is Good<br>
          OK |   13 | Voltage sensor 13 [PS2
PG Fail] is Good<br>
          OK |   14 | Voltage sensor 14 [System
Board PS1 PG Fail] is Good<br>
          OK |   15 | Voltage sensor 15 [System
Board BP1 5V PG] is Good<br>
          OK |   16 | Voltage sensor 16 [CPU1
M01 VTT PG] is Good<br>
          OK |   17 | Voltage sensor 17 [PS1
Voltage 1] reads 114 V<br>
          OK |    0 | Battery probe
0 [System Board CMOS Battery] is Presence Detected<br>
          OK |    0 | Amperage probe
0 [PS1 Current 1] reads 0.6 A<br>
          OK |    1 | Amperage probe
1 [System Board Pwr Consumption] reads 56 W<br>
          OK |    0 | Chassis intrusion
0 detection: Ok (Not Breached)<br>
          OK |    0 | SD Card 0 [vFlash]
is Absent<br>
    -----------------------------------------------------------------------------<br>
       Other messages          
                     
                     
     <br>
    =============================================================================<br>
      STATE  |  MESSAGE TEXT      
                     
                     
  <br>
    ---------+-------------------------------------------------------------------<br>
          OK | ESM log health is Ok (less than
80% full)<br>
          OK | Chassis Service Tag is sane<br>
<br>
This run exits with 1 (WARNING).<br>
<br>
We're not sure we agree with the decision to make the fact that a disk<br>
is not Dell Certified a Warning, but we can at least understand that. <br>
So, what if we exclude storage, with --no-storage?<br>
<br>
    onlight@monitor:~$ check_openmanage -H host -C secret -d
--no-storage<br>
       System:      PowerEdge R720  
        OMSA version:    7.1.0<br>
       ServiceTag:  #######        
         Plugin version:  3.7.9<br>
       BIOS/date:   1.2.6 05/10/2012    
    Checking mode:   SNMPv2c UDP/IPv4<br>
    -----------------------------------------------------------------------------<br>
       Chassis Components          
                     
                     
 <br>
    =============================================================================<br>
      STATE  |  ID  |  MESSAGE TEXT
                     
                     
 <br>
    ---------+------+------------------------------------------------------------<br>
          OK |    0 | Memory module
0 [DIMM_A1, 4096 MB] is Ok<br>
          OK |    1 | Memory module
1 [DIMM_A2, 4096 MB] is Ok<br>
          OK |    2 | Memory module
2 [DIMM_A3, 4096 MB] is Ok<br>
          OK |    3 | Memory module
3 [DIMM_A4, 4096 MB] is Ok<br>
          OK |    0 | Chassis fan 0
[System Board Fan1 RPM] reading: 1080 RPM<br>
          OK |    1 | Chassis fan 1
[System Board Fan2 RPM] reading: 1080 RPM<br>
          OK |    2 | Chassis fan 2
[System Board Fan3 RPM] reading: 1200 RPM<br>
          OK |    3 | Chassis fan 3
[System Board Fan4 RPM] reading: 1080 RPM<br>
          OK |    4 | Chassis fan 4
[System Board Fan5 RPM] reading: 1080 RPM<br>
          OK |    5 | Chassis fan 5
[System Board Fan6 RPM] reading: 1080 RPM<br>
          OK |    0 | Power Supply 0
[AC]: Presence detected<br>
          OK |    0 | Temperature Probe
0 [System Board Inlet Temp] reads 26 C (min=3/-7, max=42/47)<br>
          OK |    1 | Temperature Probe
1 [System Board Exhaust Temp] reads 33 C (min=8/3, max=70/75)<br>
          OK |    2 | Temperature Probe
2 [CPU1 Temp] reads 49 C (min=8/3, max=83/88)<br>
          OK |    0 | Processor 0 [Intel
Xeon E5-2603 0 1.80GHz] is Present<br>
          OK |    0 | Voltage sensor
0 [CPU1 VCORE PG] is Good<br>
          OK |    1 | Voltage sensor
1 [System Board 3.3V PG] is Good<br>
          OK |    2 | Voltage sensor
2 [System Board 5V PG] is Good<br>
          OK |    3 | Voltage sensor
3 [CPU1 PLL PG] is Good<br>
          OK |    4 | Voltage sensor
4 [System Board 1.1V PG] is Good<br>
          OK |    5 | Voltage sensor
5 [CPU1 M23 VDDQ PG] is Good<br>
          OK |    6 | Voltage sensor
6 [CPU1 M23 VTT PG] is Good<br>
          OK |    7 | Voltage sensor
7 [System Board FETDRV PG] is Good<br>
          OK |    8 | Voltage sensor
8 [CPU1 VSA PG] is Good<br>
          OK |    9 | Voltage sensor
9 [CPU1 M01 VDDQ PG] is Good<br>
          OK |   10 | Voltage sensor 10 [System
Board NDC PG] is Good<br>
          OK |   11 | Voltage sensor 11 [CPU1
VTT PG] is Good<br>
          OK |   12 | Voltage sensor 12 [System
Board 1.5V PG] is Good<br>
          OK |   13 | Voltage sensor 13 [PS2
PG Fail] is Good<br>
          OK |   14 | Voltage sensor 14 [System
Board PS1 PG Fail] is Good<br>
          OK |   15 | Voltage sensor 15 [System
Board BP1 5V PG] is Good<br>
          OK |   16 | Voltage sensor 16 [CPU1
M01 VTT PG] is Good<br>
          OK |   17 | Voltage sensor 17 [PS1
Voltage 1] reads 112 V<br>
          OK |    0 | Battery probe
0 [System Board CMOS Battery] is Presence Detected<br>
          OK |    0 | Amperage probe
0 [PS1 Current 1] reads 0.6 A<br>
          OK |    1 | Amperage probe
1 [System Board Pwr Consumption] reads 56 W<br>
          OK |    0 | Chassis intrusion
0 detection: Ok (Not Breached)<br>
          OK |    0 | SD Card 0 [vFlash]
is Absent<br>
    -----------------------------------------------------------------------------<br>
       Other messages          
                     
                     
     <br>
    =============================================================================<br>
      STATE  |  MESSAGE TEXT      
                     
                     
  <br>
    ---------+-------------------------------------------------------------------<br>
          OK | ESM log health is Ok (less than
80% full)<br>
          OK | Chassis Service Tag is sane<br>
    OOPS! Something is wrong with this server, but I don't know
what. The global <br>
    system health status is WARNING, but every component check
is OK. This may <br>
    be a bug in the Nagios plugin, please file a bug report.<br>
<br>
This yields exit code 3 (UNKNOWN).<br>
<br>
Now, just for argument's sake, let's say we obviate the check for<br>
certified drives, by commenting out the       "workaround
for OMSA 7.1.0<br>
bug" code (just a handy little short-cut).  Here's what we get
then:<br>
<br>
    onlight@monitor:~$ check_openmanage -H host -C secret -d<br>
       System:      PowerEdge R720  
        OMSA version:    7.1.0<br>
       ServiceTag:  #######        
         Plugin version:  3.7.9<br>
       BIOS/date:   1.2.6 05/10/2012    
    Checking mode:   SNMPv2c UDP/IPv4<br>
    -----------------------------------------------------------------------------<br>
       Storage Components          
                     
                     
 <br>
    =============================================================================<br>
      STATE  |    ID    |  MESSAGE
TEXT                    
                     <br>
    ---------+----------+--------------------------------------------------------<br>
          OK |        0 |
Controller 0 [PERC H310 Mini] is Ready<br>
     WARNING |  0:0:1:0 | Physical Disk 0:1:0 [Ata ST2000DM001-9YN164,
2.0TB] on ctrl 0 is Online<br>
     WARNING |  0:0:1:1 | Physical Disk 0:1:1 [Ata ST2000DM001-9YN164,
2.0TB] on ctrl 0 is Online<br>
          OK |      0:0 | Logical
Drive '/dev/sda' [RAID-1, 1862.50 GB] is Ready<br>
          OK |      0:0 | Connector
0 [SAS] on controller 0 is Ready<br>
          OK |      0:1 | Connector
1 [SAS] on controller 0 is Ready<br>
          OK |    0:0:1 | Enclosure
0:0:1 [Backplane] on controller 0 is Ready<br>
    -----------------------------------------------------------------------------<br>
       Chassis Components          
                     
                     
 <br>
    =============================================================================<br>
      STATE  |  ID  |  MESSAGE TEXT
                     
                     
 <br>
    ---------+------+------------------------------------------------------------<br>
          OK |    0 | Memory module
0 [DIMM_A1, 4096 MB] is Ok<br>
          OK |    1 | Memory module
1 [DIMM_A2, 4096 MB] is Ok<br>
          OK |    2 | Memory module
2 [DIMM_A3, 4096 MB] is Ok<br>
          OK |    3 | Memory module
3 [DIMM_A4, 4096 MB] is Ok<br>
          OK |    0 | Chassis fan 0
[System Board Fan1 RPM] reading: 1080 RPM<br>
          OK |    1 | Chassis fan 1
[System Board Fan2 RPM] reading: 1200 RPM<br>
          OK |    2 | Chassis fan 2
[System Board Fan3 RPM] reading: 1200 RPM<br>
          OK |    3 | Chassis fan 3
[System Board Fan4 RPM] reading: 1080 RPM<br>
          OK |    4 | Chassis fan 4
[System Board Fan5 RPM] reading: 1080 RPM</font></tt>
<br><tt><font size=2>          OK |    5
| Chassis fan 5 [System Board Fan6 RPM] reading: 1200 RPM<br>
          OK |    0 | Power Supply 0
[AC]: Presence detected<br>
          OK |    0 | Temperature Probe
0 [System Board Inlet Temp] reads 26 C (min=3/-7, max=42/47)<br>
          OK |    1 | Temperature Probe
1 [System Board Exhaust Temp] reads 33 C (min=8/3, max=70/75)<br>
          OK |    2 | Temperature Probe
2 [CPU1 Temp] reads 48 C (min=8/3, max=83/88)<br>
          OK |    0 | Processor 0 [Intel
Xeon E5-2603 0 1.80GHz] is Present<br>
          OK |    0 | Voltage sensor
0 [CPU1 VCORE PG] is Good<br>
          OK |    1 | Voltage sensor
1 [System Board 3.3V PG] is Good<br>
          OK |    2 | Voltage sensor
2 [System Board 5V PG] is Good<br>
          OK |    3 | Voltage sensor
3 [CPU1 PLL PG] is Good<br>
          OK |    4 | Voltage sensor
4 [System Board 1.1V PG] is Good<br>
          OK |    5 | Voltage sensor
5 [CPU1 M23 VDDQ PG] is Good<br>
          OK |    6 | Voltage sensor
6 [CPU1 M23 VTT PG] is Good<br>
          OK |    7 | Voltage sensor
7 [System Board FETDRV PG] is Good<br>
          OK |    8 | Voltage sensor
8 [CPU1 VSA PG] is Good<br>
          OK |    9 | Voltage sensor
9 [CPU1 M01 VDDQ PG] is Good<br>
          OK |   10 | Voltage sensor 10 [System
Board NDC PG] is Good<br>
          OK |   11 | Voltage sensor 11 [CPU1
VTT PG] is Good<br>
          OK |   12 | Voltage sensor 12 [System
Board 1.5V PG] is Good<br>
          OK |   13 | Voltage sensor 13 [PS2
PG Fail] is Good<br>
          OK |   14 | Voltage sensor 14 [System
Board PS1 PG Fail] is Good<br>
          OK |   15 | Voltage sensor 15 [System
Board BP1 5V PG] is Good<br>
          OK |   16 | Voltage sensor 16 [CPU1
M01 VTT PG] is Good<br>
          OK |   17 | Voltage sensor 17 [PS1
Voltage 1] reads 114 V<br>
          OK |    0 | Battery probe
0 [System Board CMOS Battery] is Presence Detected<br>
          OK |    0 | Amperage probe
0 [PS1 Current 1] reads 0.6 A<br>
          OK |    1 | Amperage probe
1 [System Board Pwr Consumption] reads 56 W<br>
          OK |    0 | Chassis intrusion
0 detection: Ok (Not Breached)<br>
          OK |    0 | SD Card 0 [vFlash]
is Absent<br>
    -----------------------------------------------------------------------------<br>
       Other messages          
                     
                     
     <br>
    =============================================================================<br>
      STATE  |  MESSAGE TEXT      
                     
                     
  <br>
    ---------+-------------------------------------------------------------------<br>
          OK | ESM log health is Ok (less than
80% full)<br>
          OK | Chassis Service Tag is sane<br>
<br>
Again, as with the original case, exit code is 1 (WARNING).<br>
<br>
Is there any way around this?  Should I be disabling global health<br>
checks?  Here's a run to test that, and it works:<br>
<br>
    onlight@monitor:~$ check_openmanage -H host -C secret -b
pdisk=all<br>
    OK - System: 'PowerEdge R720', SN: '#######', 16 GB ram (4
dimms), 1 logical drives, 2 physical drives<br>
<br>
Interestingly, when combining the blacklist with debug ("-d -b<br>
pdisk=all"), the exit code is 3 (UNKNOWN), but with debug off, it's
0 (OK).<br>
<br>
So, I guess what I'm wondering is why we need to blacklist the physical<br>
disks (pdisk) instead of using --no-storage?  Shouldn't --no-storage<br>
also cause globalstatus to be ignored?<br>
<br>
I can furnish SNMP walk output if that's useful.<br>
<br>
Cheers,<br>
    -nic<br>
<br>
-- <br>
Nic Bernstein                  
          nic@onlight.com<br>
Onlight, Inc.                  
          </font></tt><a href=www.onlight.com><tt><font size=2>www.onlight.com</font></tt></a><tt><font size=2><br>
219 N. Milwaukee St., Suite 2a            v.
414.272.4477<br>
Milwaukee, Wisconsin  53202<br>
<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
<br>
------------------------------<br>
<br>
------------------------------------------------------------------------------<br>
This SF.net email is sponsored by Windows:<br>
<br>
Build for Windows Store.<br>
<br>
</font></tt><a href="http://p.sf.net/sfu/windows-dev2dev"><tt><font size=2>http://p.sf.net/sfu/windows-dev2dev</font></tt></a><tt><font size=2><br>
<br>
------------------------------<br>
<br>
_______________________________________________<br>
Nagios-users mailing list<br>
Nagios-users@lists.sourceforge.net<br>
</font></tt><a href="https://lists.sourceforge.net/lists/listinfo/nagios-users"><tt><font size=2>https://lists.sourceforge.net/lists/listinfo/nagios-users</font></tt></a><tt><font size=2><br>
<br>
<br>
End of Nagios-users Digest, Vol 85, Issue 6<br>
*******************************************<br>
<br>
</font></tt>
<br>