NRPE unable to read output, but why?

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.

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.

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

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

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.

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

versus

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.

In case of custom NRPE plugins, make sure to print some output along with the exit value. If there is no output from the script NRPE will complain saying NRPE unable to read output. You can enable debugging in nrpe.cfg and observe this error.

If you can see correct output when running command directly by nagios user, but get unable to read output when running via NRPE, make sure the output you expect is not going to stderr. For example, ipmitool sel elist command will return SEL has no entries to stderr, and stderr is not captured by nrpe. You can add 2>&1 to redirect stderr to stdout in such case.

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/check_mem.sh
-rwxr--r-- 1 root root 1598 Jul  7 10:55 /usr/lib/nagios/plugins/check_mem.sh

NRPE server :

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

After : Remote Host :

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

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

Problem Resolved.

In my case the issues was selinux related (running RHEL 6.5, selinux is set to enforcing).

Installing nagios-plugins-* via yum will create your plugin files in /usr/lib64/nagios/plugins. If you check the fcontext on those plugin files (ls -lZ), you will see the files have the context type set to "nagios_system_plugin_exec_t", which is the context type that check_nrpe expects.

In my case, I had created a custom script "check_mem.sh" using "vi". The resulting file had the context type set to "lib_t". This was causing nrpe to output the "NRPE: Unable to read output".

Changing the file context to "nagios_system_plugin_exec_t" solved the issue:

chcon -t nagios_system_plugin_exec_t /usr/lib64/nagios/plugins/check_mem.sh

The usual selinux troubleshooting would have pointed me to this issue as well (checking /var/log/audit/audit.log), but it was ofcourse the last thing I thought about

Edit: chcon just temporarily changes the context. To change it persistently use semanage fcontext -a -t nagios_system_plugin_exec_t /usr/lib64/nagios/plugins/check_mem.sh restorecon -vF /usr/lib64/nagios/plugins/check_mem.sh

In my case the log file being monitored was owned by root:adm, so adding the nagios user to the adm group made the check_log command succeed, but only when executed directly on the monitored hosts. It continued to fail using check_nrpe on the Nagios server until I restarted the nagios-nrpe-server service on the monitored hosts, e.g.

service nagios-nrpe-server restart

So apparently restarting the service was necessary to make the permissions change take effect for NRPE, but it took me a while to figure this out.