NRPE unable to read output, but why?

Question

I have this problem with NRPE, all the stuff I've found so far on the net seems to point me at things I've already tried.

# /usr/local/nagios/plugins/check_nrpe -H nrpeclient

gives

NRPE v2.12

as expected.

Running the command by hand (as defined in nrpe.cfg on "nrpeclient", gives the expected response

nrpe.cfg:

command[check_openmanage]=/usr/lib/nagios/plugins/additional/check_openmanage -s -e   -b ctrl_driver=0 bat_charge

"Expected response"

But if I try to run the command from the Nagios server I get the following:

# /usr/local/nagios/plugins/check_nrpe -H comxps -c check_openmanage
NRPE: Unable to read output

Can anyone think of anywhere else I might have made a mistake with this? I've done the same thing on multiple other servers with no problem. The only difference I can think of with this is that this box is RHEL 5 based, whereas the others are RHEL 4 based.

Those two bits above that I've tested are the what most people seem to suggest when people have had this problem.

I should mention that I get a weird error in the logs when I restart nrpe:

nrpe[14534]: Unable to open config file '/usr/local/nagios/etc/nrpe.cfg' for reading 
nrpe[14534]: Continuing with errors...
nrpe[14535]: Starting up daemon
nrpe[14535]: Warning: Daemon is configured to accept command arguments from clients!
nrpe[14535]: Listening for connections on port 5666 
nrpe[14535]: Allowing connections from: bodbck,combck,nam-bck

Even though, it's plainly reading that /usr/local/nagios/etc/nrpe.cfg file to get the stuff it's talking about further down..

Solution 1

You have a rights problem.

Change the command to:

command[check_openmanage]=sudo /usr/lib/nagios/plugins/additional/check_openmanage -s -e -b ctrl_driver=0 bat_charge

(add sudo)

Then, add the nagios-user to the sudoers:

nagios ALL=(ALL) NOPASSWD:/usr/lib/nagios/plugins/additional/check_openmanage

Or you could just chmod the file... That also works.

If you are using CentOS, Red Hat, Scientific or Fedora, make sure to disable Defaults requiretty in the sudoers file.

Solution 2

Short answer : if you're using a Bash plugin, make sure you have a shebang stating which interpreter should be used : #!/bin/bash

---

I was facing the same issue with a Nagios plugin I wrote myself. The script was running as expected when launched locally, even when running as user nagios using following statement :

$ sudo sudo -s -u nagios
$ /path/to/my/plugin.sh
STATUS: OK

But remote-launching using NRPE from the Nagios3 server was unsuccessful :

$ /usr/lib/nagios/plugins/check_nrpe -H my-nagios-client -c my_plugin
NRPE: Unable to read output

I finally solved this case by adding a shebang in my script, as it appeared that running the script through NRPE did not used the same interpreter as when running through sudo sudo -s -u nagios.

Solution 3

In my case problem was simply - user nagios was not able to execute the script. After chmod it started to worked. Sudo is not necessary. Its even evil :)

Solution 4

In my case, only one plugin failed while several others worked okay. It turned out to be a LOCALE problem.

The plugin was check_mem.sh and it performed a grep for Mem in the output of free. But system wide LOCALE returned Speicher (German) instead of Mem, so all received values were empty strings.

Solution 5

check_nrpe was getting 'NRPE: Unable to read output' despite the check working locally because the plugin I was using did not work well with SELinux. Disable it and make sure to remove the file's contexts:

$ ls -l check_om_storage
-r-xr-xr--. 1 root nrpe 3808 Feb 27 17:54 check_om_chassis
$ setfattr -x security.selinux check_om_storage
$ ls -l check_om_chassis 
-r-xr-xr-- 1 root nrpe 3808 Feb 27 17:54 check_om_chassis

View more solutions

Comments

[mailq]

possible duplicate of NRPE unable to read output, but why?

[Ahmad Hajjar]

@Bart De Vos but the answer you added will make a security hole > adding something to the sudoers file open you up for a potential security risk. i.e. if via a buffer overflow someone is able to drop a file with the same name in the same location, they could execute it without knowing the root password and gain control of the box :S Is there no way to somehow put a signature (SHA1 or MD5) of the application in the sudoers file to prevent that type of attack. i.e. the injected file won't have the same signature and thus doesn't execute. [Read the first comment here](crashatau.blogspot.co

[APR]

@X-Ware: While this is true, the chance a buffer overflow could be abused here is very slim. To prevent it from happening however, you should use apparmor/SELinux. That is why these things exist.

[TrinitronX]

Had this problem when using a ruby script nagios plugin with rbenv. Fix was to create a wrapper script with #!/bin/bash -el eval "$(rbenv init -)" /usr/lib/nagios/plugins/check_something $@

[droope]

The real answer is this. Nagios was not able to execute the script, either due to bad permissions, the script being mispelled, or the script not being there.

[Admin]

I guess different distros even have different users, in my case the user to add to visudo was npre not nagios. I still followed Bart De Vos's solution, however you can see which user is trying to access the nrpe command by viewing the /var/log/secure access log. Jul 24 15:39:09 hostname sudo: nrpe : user NOT in sudoers ; TTY=unknown ; PWD=/ ; USER=root ; COMMAND=/usr/lib64/nagios/plugins/check_disk -w 20% -c 10% -p /dev/mapper/vg_uxp-lv_root

[Itai Ganot]

The link has been updated

[austinian]

Good answer, but it's also good to note that allowing all users to run check_nrpe, as chmod o+x does, could be a potential security risk, depending on how the system is configured/accessed/used.

[MadHatter]

Rush, welcome to SF! This is an excellent first answer, in my opinion: short, to the point, and it adds something new to the collection of answers already here. +1 from me, and I hope to read more such answers from you in the future (I hope you will forgive my small formatting edit).

[Dennis Nolte]

while disabling selinux generally might not be a good idea for testing this is imho still valid.

[Evan Langlois]

@AhmadHajjar Are you serious? You think someone will hack nagios (a system thats 20 years old) and use that user to execute a file with root permissions. AND you think I didn't make the executable to be run as root as read-only to prevent someone from copying a file over it? If you are worried about it, instead of using sudo you can setuid the check_openmanage executable itself and let anyone run it!

[I say Reinstate Monica]

Welcome to Server Fault. Can you provide more detail explaining how/why this works?