NRPE Repotting timeouts

[Mohr James]

Hi All!

In order to record performance data, we have a construct that looks like
this:

- Nagios starts an NRPE job on another machine which starts a perl
script on a Windows 2003 machine
- the perl script uses the snmpget command from net-snmp 5.2.1 to read a
single value from a remote machine. 
- The value is set in the perl script simply by $value=`$command`. (I am
not using the SNMP perl modules)
-  The OID .1.3.6.1.4.1.1.1.101.1 is defined like this in snmpd.conf: 
exec .1.3.6.1.4.1.1.1 /usr/bin/perl /opt/elaxy/bin/get_cpu_usage.pl
- This value is then written to a MS SQL Database using osql. 

What is happening is that I see dozens of snmpget.exe programms running
(occassionally a couple of perl.exe processes). Unfortunately, I see no
way of figuring out to where these processes are connected, so I cannot
tell if there are specific machine causing the problems. Using netstat,
I do see a number of connections to the MS SQL database in TIMEWAIT.
However, since we are checking a couple of dozens machines, this is not
surprising. 

The Nagios is reporting both "CHECK_NRPE: Socket timeout after 10
seconds." and "connection refused". Obviously this could be a purely
net-snmp problem, however, as far as I can see it seems to be behaving
correctly. Since I can run the commands by hand with no problem, I am at
a loss to explain where net-snmp (snmpget) is having a problem.

Any ideas would be greatly appreaciated.

Regards,

Jim Mohr 


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&op=click
_______________________________________________
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