patch: nrpe "invalid CRC32" when command outputs to stderr

Simon Kitching simon at ecnetwork.co.nz
Fri Mar 5 06:30:25 CET 2004


Hi,

When using nrpe in inetd mode, if the command that is executed by nrpe
outputs any data to stderr, then the message
  CHECK_NRPE: Response packet had invalid CRC32.
is output.

I described the issue and its cause in an email to the users list a few
months ago. As there were no offers to fix it, here is a patch.

How to demonstrate the problem:
* create shellscript /tmp/dostderr containing:
  #!/bin/sh
  echo "an error" 1>&2
  echo "an output"
  exit 0
* set up an nrpe config file with the following:
  command[check_stderr]=/tmp/dostderr
* set up nrpe to run from inetd

run:
  ./check_nrpe -H localhost -c check_stderr

The cause:

When inetd forks and creates an nrpe process after a user connects, the
created process has both STDOUT and STDERR connected to the socket back
to the client. When popen is used to execute the actual command, the
spawned command's STDOUT goes into the pipe that nrpe explicitly reads
from. However the spawned command's STDERR is not overridden - so any
output by the command to stderr goes immediately and directly back to
the remote client process.

The result is that if the command writes to STDERR, then the client
(check_nrpe) sees this output before nrpe writes the "packet header" and
therefore interprets the result as a packet with corrupt checksum.

The fix:

In inetd mode, force STDERR to map to/dev/null. Any STDERR output
generated by the command therefore is discarded. It would be even nicer
to cause a command's stderr and stdout to be "merged", but I can't see
any way to do that without replacing the "popen" call with something
significantly smarter. 

The daemon mode doesn't experience this problem, because STDERR is
already redirected to /dev/null using the same technique.

Maybe the "popen.c" file in the main nagios distribution could be used
here, but that would be a much bigger fix. At least the minimal fix
attached here solves the main problem (strange CRC32 error).

Regards,

Simon

-------------- next part --------------
A non-text attachment was scrubbed...
Name: nrpe.crc.patch.txt
Type: text/x-patch
Size: 741 bytes
Desc: not available
URL: <https://www.monitoring-lists.org/archive/developers/attachments/20040305/b6673acf/attachment.bin>


More information about the Developers mailing list