can't get host to display in Host Detail panel

Jonathan Wiggins jwiggins at salon.com
Tue Oct 12 04:15:06 CEST 2010


On Sep 29, 2010, at 5:47 AM, Assaf Flatto wrote:

> 
>> Assaf - thanks for your time and patience outlining those steps:
>> 
> 
> That is what the list is about .
> 
>> I was able to at least get the connectivity between Nagios server and the monitored host to show a valid connection:
>> 
>> /usr/local/nagios/libexec/check_nrpe -H 10.0.100.139 -c check_users
>> USERS OK - 1 users currently logged in |users=1;5;10;0
>> 
>> there were a few things wrong on the monitoring server, or at least what I changed:
>> 
>> * changed ownership of nrpe.cfg to nagios.nagios
>> * modified xinetd.d/nrpe to show Nagios server IP as allowed connection
>> 
>> I struggled with a few other things, and connection attempts, before I realized I hadn't restarted the nrpe service after modifying the xinetd.d/nrpe file.
>> 
>> I did notice that the plugin location from another server is different than the one that is missing:
>> /usr/lib64/nagios/plugins vs /usr/local/nagios/libexec/  (guess this has something to do with the way it was compiled)
> 
> NRPE by default is placing the path as the lib64  in the nrpe.cfg sample file , while all other  packages use the local path - this is something that you get used to "ignore-modify " with time .
>> Guess I have to wait now a few mins before the host shows in the panel? as its not showing now even after 10 mins.  Restarting xinetd shows this in /var/log/messages:
>> 
>> xinetd[22518]: bind failed (Address already in use (errno = 98)). service = nrpe (is this a bug or anything in xinetd? I saw that referenced on a few other forums)
>> 
>> nrpe service is running and listening though on 5666
> I have always run nrpe as a stand alone daemon , never with xinetd , to have better control on what is running and how it is run .
> 
> From what i remember about xinetd , it has an internal "keep-alive" mechanism that waits till all connections are terminated before it releases a port (again , i may be wrong ) you  need to stop it and wait till the port is no longer shown as active , and then restart it .
> 
> Or move to a standalone daemon - that will allow you to control the nrpe separately from any other service and  better debug the issue.
> 
> 
> 



I had to take a break from this project, but now I'm circling back to it.

I am able to connect from the nagios server to the monitored node (this server has (2) IP's as it's eth0 has an IP alias bound to it, hence checking both IP's):

bash-3.1# /usr/local/nagios/libexec/check_nrpe -H 10.0.100.139
NRPE v2.12
bash-3.1# /usr/local/nagios/libexec/check_nrpe -H 10.0.100.138
NRPE v2.12

I can use another event handler:

bash-3.1# /usr/local/nagios/libexec/check_nrpe -H 10.0.100.139 -c check_users
USERS OK - 1 users currently logged in |users=1;5;10;0
bash-3.1# /usr/local/nagios/libexec/check_nrpe -H 10.0.100.138 -c check_users
USERS OK - 1 users currently logged in |users=1;5;10;0

I can also telnet from the Nagios server to the monitored host:

bash-3.1# telnet 10.0.100.139 5666
Trying 10.0.100.139...
Connected to 10.0.100.139 (10.0.100.139).

but... 

I am still getting an SSL failure on the handshake?

Oct 11 19:12:43 mywebserverB nrpe[17659]: Error: Could not complete SSL handshake

But back to xinetd; does seem that its not binding or starting with NRPE correctly (not sure if this is why its not connecting)

{missing server in host panel}:

Oct 11 18:28:37 mywebserverB xinetd[23960]: Exiting...
Oct 11 18:28:38 mywebserverB xinetd[24300]: xinetd Version 2.3.14 started with libwrap loadavg labeled-networking options compiled in.
Oct 11 18:28:38 mywebserverB xinetd[24300]: Started working: 0 available services



{server showing in host panel}:

Oct 11 18:32:34 mywebserverA xinetd[3579]: Exiting...
Oct 11 18:32:34 mywebserverA xinetd[28455]: xinetd Version 2.3.14 started with libwrap loadavg labeled-networking options compiled in.
Oct 11 18:32:34 mywebserverA xinetd[28455]: Started working: 1 available service


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.monitoring-lists.org/archive/users/attachments/20101011/2d990744/attachment.html>
-------------- next part --------------
------------------------------------------------------------------------------
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2 & L3.
Spend less time writing and  rewriting code and more time creating great
experiences on the web. Be a part of the beta today.
http://p.sf.net/sfu/beautyoftheweb
-------------- next part --------------
_______________________________________________
Nagios-users mailing list
Nagios-users at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nagios-users
::: Please include Nagios version, plugin version (-v) and OS when reporting any issue. 
::: Messages without supporting info will risk being sent to /dev/null


More information about the Users mailing list