On Sep 2, 2008, at 11:21 PM, J. Bakshi wrote: > I'm not using xinetd. I'm using nrpe daemon instead. > May be my firewall is responsible for the problem but I'm not sure > Even after increasing the time with -t 20 the commands still report > socket time out :-(
Why not try xinetd with a simple firewall rule? I believe most people use xinetd or inetd and thus you should be able to get the most help that way. I set it up the same way the documentation states. http://nagios.sourceforge.net/docs/nrpe/NRPE.pdf Have you successfully installed NRPE before? If not, it may be time to move to a testing environment that you can have full control over. That being said... Are you running SElinux? Have you checked out your relevant logs for nrpe, iptables, selinux, etc (/var/log/messages, make sure debugging is turned on with NRPE)... It may be give you some interesting information. I like to run tail on the problem server then try NRPE from the monitoring server to see what is going on. # REMOTE SERVER running NRPE daemon continuosly running tail $ tail -f /var/log/messages Sep 4 09:35:03 dev2 nrpe[7118]: INFO: SSL/TLS initialized. All network traffic will be encrypted. Sep 4 09:35:03 dev2 xinetd[32709]: EXIT: nrpe status=0 pid=7118 duration=2(sec) ... # NAGIOS SERVER running 'check_nrpe -H REMOTEHOST' or have nagios run checks till they start to timeout. $ ./check_npre -H REMOTEHOST NRPE v2.11 Good luck! Mark Young ___ Nagios Enterprises, LLC Web: www.nagios.com ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Nagios-users mailing list Nagios-users@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
