Nrpe messages

[Carroll, Jim P [Contractor]]

Brian Whitehead wrote:
> I had a similar issue once.  It turned out to be a change I made me
> ipchains rules.  Check both your client and server tcp/ip configs and
> any firewalling you may have setup.  If you're running 
> ipchains/iptables
> or anything similar, try flushing all of the rules.  Make 
> sure tcp/ip is
> not misconfigured, like an incorrect subnet mask.  Once 
> you've gone over
> it all, try restarting xinetd, assuming you setup nrpe to be run from
> xinetd.

My configuration:

Nagios (server)
  - Red Hat Linux 7.3 2.96-110
  - Dell Optiplex GX1

Client experiencing problem (one example)
  - Solaris8 (SunOS 5.8)
  - Sun Enterprise E6500
  - nrpe running as standalone

The problem is extremely sporadic.  I would think that if it were a firewall
config problem, I would be having *no* success, but that's not the case at
all.  It runs fine for a while, then on a non-deterministic basis, the
problem rears its ugly head.  One 'could not read request' error, then it
runs fine for a while.

The problem doesn't appear at the same time of every hour, nor does it
appear at the same time of every day, so it's unlikely to be related to a
cronjob.

I mentioned in a previous message that I even ran a loop (with no sleeps)
like the following one (from the Nagios server) and it chugged happily
along, returning results with every iteration:

while :
do
  check_nrpe [whatever]
done

When I run 'top' on the Nagios server, the CPU is 97% idle.

The only thing that springs to mind is that 'netstat -i' does report some
errors.  (Does anyone have a good reference on which errors 'netstat -i'
produces that are work sitting up and paying attention to?)

Actually, there are 1 or 2 other things that might remedy the problem.
Migrating to a beefier box, and/or moving the existing box from the current
(test) location (4-port workgroup hub connected to the upstream switch) over
to the main switch where the majority of the monitored systems are.  It
could be that the 4-port hub isn't up to snuff, and certainly eliminating
this from the equation would make me more confident.

I'm still open to suggestions.

jc


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf