Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

Im getting the same old "Unable to read output" message from this NRPE test. I can run other tests on this machine and I can su - nagios -c "<path to check_aacraid>" when running locally and it works.

Looking at /var/log/messages shows that the process is opened and started - it just doesn't seem to give back any message(s) that NRPE can digest.

What else can I use to debug this? I've set debug = 1 in "nrpe.cfg" and I have nagios set in sudo as NOPASSWD:ALL. (yes, its a big security hole.. I'm getting desperate to make this work)

Both systems (nagios server and NRPE client) are CentOS 6.2.

EDIT:

to test from the Nagios server I've been using a cmdline:

/usr/local/nagios/libexec/check_nrpe -H <IP of nrpe machine> -c check_aacraid

This works ok if I try "check_users" or "check_total_procs" (defaults that come with NRPE installation). It also works if I rename one of these commands to "stuff" and pass that with the -c to "check_nrpe". This leads me to believe that the issue isn't server-side nagios.

On the client side, the only change I've made to NRPE.CFG (outside of testing - see above) is to add a line:

command[check_aacraid]=/usr/local/sbin/check-aacraid.py

Otherwise everything is default.

I can execute this command when logged in as 'nagios' and also via 'su - nagios -c "cmd"'.

share|improve this question
    
Please, post the related configuration from nagios server and nrpe server (defined command on both systems) and how you are executing the command manually. You may be missing some parameter or executing it in a different way. –  Khaled May 1 '12 at 13:14
    
edits are inline. –  ethrbunny May 1 '12 at 13:21
    
Why did you do NOPASSWD:ALL in /etc/sudoers? Does the Python script do a 'sudo'? –  Jeff Leyser May 1 '12 at 13:59
    
@JeffLeyser - yes. There are more sudos in the script. The script isn't v long so Im nearing the point of ditching it and recoding it. This is annoying. –  ethrbunny May 1 '12 at 14:08
    
When you run the check script from the command line, what output do you get? –  Jeff Leyser May 1 '12 at 14:29
show 1 more comment

4 Answers

I would say that the PATH in your interactive shell is nice and long and includes everything that check_aacraid needs, but the NRPE PATH is short and sweet, and lacks something that you need. Pick your favourite method for enhancing the PATH for check_aacraid, and chances are all your problems will go away.

As an aside, the general diagnostic method for NRPE is to strace -f -s 1024 the PID of the NRPE server, and just watch what happens. It's usually pretty obvious what's going wrong.

share|improve this answer
    
Paths: I wondering about this. I was hoping to eliminate it by testing via su - nagios -c "cmd". Also - Im running NRPE in xinetd. Can I use strace for that? –  ethrbunny May 1 '12 at 14:23
    
Your su testing won't work, because it won't necessarily emulate the PATH being used by NRPE. You can strace any running process with the -p option. –  womble May 2 '12 at 0:46
    
I've been working this avenue. strace gives me a tremendous amount of information to sift through. –  ethrbunny May 3 '12 at 13:38
    
It's usually pretty easy to find the plugin invocation you're looking for with a simple text search, and then since it's a PATH issue you're interested in, take a look for execve calls in that child. –  womble May 3 '12 at 14:34
add comment

The sudo in the script is probably failing because it's not on a tty when NRPE runs. Check /etc/sudoers for:

Default requiretty

And comment it out.

share|improve this answer
    
Did that already. Early on. –  ethrbunny May 1 '12 at 14:18
add comment

You likely have tried this already but I was running into this same issue with anther plugin. The solution on my end was to add this line to the nrpe.cnf: command[check_aacraid]=sudo /usr/local/sbin/check-aacraid.py

in the sudoers file:

nagios ALL=NOPASSWD:/usr/local/bin/check-aacraid.py

In addition to the commenting out of Default requiretty that you mentioned was already done.

share|improve this answer
    
Tried that too. –  ethrbunny May 3 '12 at 13:37
    
I know it's not advisable but have you tried running just straight up as root instead of having it sudo? –  Rob May 3 '12 at 15:55
add comment
up vote 0 down vote accepted

The 'problem' turns out to be SELinux. When I 'echo 0 /selinux/enforce' the plugin works. Now to figure out how to work with the system instead of around it.

share|improve this answer
add comment

Your Answer

 
discard

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.