[Nagiosplug-help] check_nrpe build sucks

Ralph.Grothe at itdz-berlin.de Ralph.Grothe at itdz-berlin.de
Thu Jul 14 23:37:38 CEST 2005

Hello Erwin,

> Did you by any chance take the nrpe.cfg.in file directly out of
> source distribution and modify that? That's where the "macro"
> placeholders came in, and yes, they're supposed to have things
> substituted in during the build. I can see where your confusion
> from, then.
> You should have ended up with an nrpe.cfg file in the top level
of the
> source tree after the build, with the substitution done on the
> That's how I got server_port defined.
> @libexecdir@ should point to wherever your local plugins

That's it, a minute misconception, severe effect.
I must have accidentally taken a copy of nrpe.cfg before the make
process had a chance to substitute the placeholders.
So I edited nrpe.cfg and had vi filewide substitute all
occurrences of @libexecdir@ by the actual path.
I also correctly populated nrpe_(port|user|group).
As you said, it cannot hurt to be explicit.

Now it partially works, i.e. on the remote host alone by that
host's check_nrpe pointed to localhost.

Because for first tests the check_oracle seems too involved I on
the fly added another check command definition.
For now I didn't care much for well suited options, so with all
the local filesystems mounted and being in one line reported (I
guess a Nagios requirement for plug-ins) this produces some line

# grep check_disk_locpct /usr/local/nagios/etc/nrpe.cfg
-w 10% -c 5% -l 

# /usr/local/nagios/libexec/check_nrpe -H -c
DISK WARNING - free space: / 74 MB (53%); /stand 45 MB (55%);
/var 39 MB (6%); /var/www 440 MB (87%); 
/usr 80 MB (7%); /usr/local/tmp 599 MB (40%); /tmp 20 MB (17%);
/opt 42 MB (7%); /home 44 MB (55%); /b
s14 1192 MB (59%); /bs12 3358 MB (94%); /bs11 959 MB (94%); /b062
526 MB (99%); /b051 5692 MB (66%); /
apptemp 1100 MB (55%); /u03 19493 MB (23%);| /=66MB;126;133;0;140
/stand=37MB;72;76;0;81 /var=661MB;63
0;665;0;700 /var/www=68MB;457;482;0;508
/usr=1029MB;997;1052;0;1108 /usr/local/tmp=901MB;1350;1425;0;1
500 /tmp=100MB;108;114;0;120 /opt=598MB;576;608;0;640
/home=36MB;72;76;0;80 /bs14=840MB;1828;1930;0;20
32 /bs12=226MB;3225;3404;0;3584 /bs11=66MB;921;972;0;1024
/b062=7MB;478;505;0;532 /b051=2981MB;7804;82
38;0;8672 /apptemp=900MB;1800;1900;0;2000

However it still doesn't work for a check_nrpe from the Nagios
>From there I run into the default socket timeout.

There is no firewall, packet filter, or miscreant router between
Nagios server and remote host

$ nmap -P0 -p 5666 terra|grep -v terra

Starting nmap V. 2.53 by fyodor at insecure.org (
www.insecure.org/nmap/ )
Port       State       Service
5666/tcp   open        unknown                 

Nmap run completed -- 1 IP address (1 host up) scanned in 0

Because standard HPUX comes with a poorman's TCP wrapper (i.e.
I moved this file out of place.
According to the manpage you're left with only the security the
inetd spawned server implements 
if that file does not exist.

This is what happens when I run the check from the Nagios server
(n.b. DNS lookups either way work, and I also tried specifying
the IP address of remote server,
that's what I will configure into services.cfg to avoid DNS
I just didn't want to reveal IP addresses, which is daft paranoia
I suppose)

$ libexec/check_nrpe -H terra -p 5666 -c check_disk_locpct
CHECK_NRPE: Socket timeout after 10 seconds.

This is what gets written to remote host's syslog.log

# tail -1 /var/adm/syslog/syslog.log
Jul 15 08:28:20 terra nrpe[14690]: Could not read request from
client, bailing out...

Do I now have to do packet sniffing to get a clue what's
misbehaving, or can anyone give me a hint?

More information about the Help mailing list