Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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


NRPE v2.12

as expected.

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


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..

share|improve this question
possible duplicate of NRPE unable to read output, but why? – mailq Oct 20 '11 at 11:44
Let's keep this one, since the other one was closed. – Bart De Vos Oct 20 '11 at 11:57
Also, ensure that STDOUT is actually flushed. – user156400 Jan 28 '13 at 11:50

13 Answers 13

up vote 25 down vote accepted

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.

share|improve this answer
Worked a treat! Thanks! – ticktockhouse Oct 20 '11 at 13:36
@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]( – Ahmad Hajjar Mar 16 '12 at 9:45
@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. – Bart De Vos Mar 16 '12 at 13:15
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 – user234448 Jul 24 '14 at 19:43

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/

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.

share|improve this answer
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 $@ – TrinitronX Oct 3 '13 at 21:45
amazing answer! sudo -s -u nagios allowed me to see why nagios couldn't return output from a specific plugin. thank you so much! – ufk Jan 21 '15 at 15:00

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
share|improve this answer
while disabling selinux generally might not be a good idea for testing this is imho still valid. – Dennis Nolte Feb 24 at 12:21

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 :)

share|improve this answer
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. – droope Oct 8 '13 at 2:46

Check pathing, permissions, selinux, iptables.

Mine was a pathing issue in client:nrpe.cfg, double check the command path to the check_* plugin name. These can be confusing, (lib/local) (libexec/plugins) as a pathname. I mistakenly yanked and put the paths from the commented prepackaged nrpe cfg file to make commands. The make install or yum plugin install puts these in a difft directory.

commaneted: /usr/local/nagios/libexec/check_disk


realpath: /usr/lib/nagios/plugins/check_disk

From the server I was able to confirm it was not a firewall issue, could telnet to the 5666 port, could run a blanket check_nrpe and get the status as a return value. Could run the commands locally but nrpe had the wrong path on the client in the nrpe.cfg.

share|improve this answer

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

The plugin was 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.

share|improve this answer
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). – MadHatter Feb 24 at 12:00

This is a permission issue, just give the script execution right and it will be ok :

here an example : Before / Remote host:

[root@puppet1 nrpe.d]# ls -l /usr/lib/nagios/plugins/
-rwxr--r-- 1 root root 1598 Jul  7 10:55 /usr/lib/nagios/plugins/

NRPE server :

[root plugins]# ./check_nrpe -H -c check_mem_vb
NRPE: Unable to read output

After : Remote Host :

[root@puppet1 plugins]# chmod o+x /usr/lib/nagios/plugins/

[root plugins]# ./check_nrpe -H -c check_mem_vb
Memory: OK Total: 1980 MB - Used: 139 MB - 6% used|Total=2076479488;;;Used=145076224;;;Cache=1528111104;;Buffer=211890176;;;

Problem Resolved.

share|improve this answer
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. – austinian Jul 8 '15 at 18:51

It could be that you haven't installed your Nagios plugins, NRPE cannot find them, or access them.

I have never had to add my commands to Sudoers. Make sure commands are owned by the Nagios user and they are readble.

share|improve this answer

I Think you must add the plugins in your local dir /usr/lib64/nagios/plugins/*. I had the same problem as you and i can solve it with this solution.

share|improve this answer

I had the problem that you write. The test I ran was from perl. Put this line into the file /etc/nagios/nrpe.cfg to make it work.

command [check_memory] = /usr/bin/perl /usr/lib64/nagios/plugins/check_memory -w 75-c 90 
share|improve this answer

There's a really nice article which covers the whole NRPE agent installation and configuration with many check_commands examples, I use this article when ever I need to install NRPE on a new server. More than that, in the end of the page you can find a cool script which automatically installs and configures NRPE for you (based on variables you set), the article can be found: Here

share|improve this answer
The link has been updated – Itai Ganot Jan 20 '15 at 22:25

This usually happens when NRPE server is started with the user nrpe, instead of nagios.

Changing the nrpe_user value into nagios in the /etc/nagios/nrpe.cfg file should solve your problem.

The nrpe_group can be changed too if needed.

share|improve this answer

Missing Nagios plugins on the nrpe client.

Do not use yum install nagios-plugins ( nagios-plugins-2.0.3-1.el6.x86_64). It does not install all the plugins. Download nagios-plugins-1.4.11.tar.gz and follow instruction in this document.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.