Hi all
Yet another problem concerning NRPE, i have browsed around but was unable to find any info on this particular problem so here goes.
I have installed NRPE on a RedHat Linux machine (2.6.9-11.ELsmp precompiled RHEL4 thing), it is configured to run via xinetd with the following config:
# default: on
# description: NRPE
service nrpe
{
flags = REUSE
socket_type = stream
wait = no
user = cadm
server = /q/disk_0/nrpe-2.0b3/nrpe
server_args = -c /q/disk_0/nrpe-2.0b3/nrpe.cfg -i
log_on_failure += USERID
disable = no
only_from = 130.225.194.53 127.0.0.1
}
It is installed in /q/disk_0/nrpe-2.0b3/ on the machine and nrpe.cfg contains the following:
Here comes the problem, upon running check_nrpe from my monitoring host, i get the well known error receiving data from daemon.
However doing a telnet from monitor host to nrpe host, works fine and doing “check_nrpe -H nrpehosthere” gives me the response “NRPE v2.0”.
Also looking at the logs on the NRPE host it seems like everything works fine, SSL handshake and so on.
Running check_disk on the NRPE host directly also reports the correct answer, so it must be the monitoring host, however i can get no further log messages (or i don’t know where to look or enable).
To complete the strangeness, i did the exact same installation 2 days ago on a machine that is 100% identical in hardware and operating software, only difference is number of mounted partitions…and it worked with no problems.
Anyone experienced this before, or got any ideas as to what might be wrong?
Are you absolutely sure you configured NRPE to allow arguments? Try setting dont_blame_nrpe=0 and then configure Nagios to use the alternative command for checking disk space (check_disk1 by default). Try to execute the command remotely and see if it works for you. I’m guessing it might be that simply because you can execute the command to check the NRPE version, but your error comes when trying to execute the actual check command.
Futhermore NRPE or Nagios (can’t recall which) complaints when arguments are passed and it is not compiled with argument support, that was my problem on some other host a few months back.
Problem solved…i was retarded enough to forget to check execution permissions on the plugins…only root had access and the service is not running as root.
