check_log problem on x86_64 - NRPE:Unable to read output


#1

We have a fairly large nagios setup, running the standard Fedora nagios packages. E.g. nagios-2.9-1.fc6, nrpe-2.7-3.fc6.

The strange thing is for some reason, the our x86_64 based clients are unable to run the check_log NRPE client. The master is reporting, “NRPE: Unable to read output”.

Note that in our setup, the nagios server is running on a i686, FC6. On our i686 client machines, everything works fine. I.e., all NRPE clients work.

On the x86_64 client machines, all NRPE commands work: LOAD, PROCS, FREE_SPACE, etc., but NOT check_log. We have checked permissions, etc. On the client machines:

su - nagios

$ sudo /usr/lib64/nagios/plugins/check_log -F /var/log/messages -O ~/check_log.messages.old -q “some error string”

Log check ok - 0 patter matches found

However, when the NRPE server tries to do this, we see the “NRPE Unable to read output” error. It is also clear that the client check_log is not even running because the -o output file is not being updated.

One further note, our nrpe client is run under xinetd. Again, all other NRPE commands are working.

Any ideas?

Thanks!
Halloo Support


#2

add this to your sudoers file on the clients you want to run check_log on:

nagios ALL=(ALL) NOPASSWD: /usr/lib64/nagios/plugins/check_log

And try again. If it still doesn’t work, remember your nrpe config on the client should have the sudo in it. eg:
command[check_my_logs]=sudo /usr/lib64/nagios/plugins/check_log -F /var/log/messages -O ~/check_log.messages.old -q “some error string”

lemme know if that works


#3

Dear MP,

Our sudoers file is already correct. In the first post you can see that we tested that by changing to the nagios user “su - nagios”, and then running the command as nagios: “sudo /usr/lib64… etc”


#4

Found the answer! Looking at /var/log/secure, the problem reveals itself. The answer is here:
nagios-portal.de/wbb/index.p … =82503&l=2

Basically, for some reason, the x86_64 version of Fedora has has

Default requiretty

in its /etc/sudoers file. Commenting this out fixes the problem!

Thanks,
Halloo Support


#5

thanks for coming back to post your solution!