summaryrefslogtreecommitdiffstats
path: root/ACKNOWLEDGEMENTS
diff options
context:
space:
mode:
authorAnton Lofgren <alofgren@op5.com>2013-10-18 09:42:46 (GMT)
committerHolger Weiss <holger@zedat.fu-berlin.de>2013-11-19 22:57:27 (GMT)
commit77fc3548ae1be360584082d771fa01696d4f4479 (patch)
tree3410cca89724e1fa1fa64eb94b83422f5d5774ae /ACKNOWLEDGEMENTS
parentdc3fc90e2a799e9f835a2d10d824bfcb20128d3d (diff)
downloadmonitoring-plugins-77fc3548ae1be360584082d771fa01696d4f4479.tar.gz
check_procs: ignore plugin parent process
This fixes an issue that appears when running check_procs over NRPE, where the default shell is configured to (for example) dash, as is the case on Debian. dash (and tcsh, and mksh, and probably others), when invoked with -c forks an additional process to execute the argument string. Contrast this with bash, which does not do this, provided that the argument string simply can be exec()'d as-is. To demonstrate: $ bash -c pstree init─┬ .. ... ├─sshd─-─sshd───pstree versus $ dash -c pstree init─┬ .. ... ├─sshd─-─sshd───dash───pstree The consequence of this fork is that the following invocation: /opt/plugins/check_procs -a init will result in this output: PROCS OK: 2 processes with args 'init' | processes=2;;;0; because the check_procs, in addition to finding the actual init process, finds its parent shell as well. This example is a bit contrived, but I think it illustrates the point. This wouldn't really be a problem, and normally isn't, if it weren't for the fact that NRPE uses a call to popen() which does exactly the above (executes '/bin/sh -c ...'), causing inconsistent behaviour between distributions and much confusion for end users. The argument may be made that the dash process spawned by NRPE is just a process like any other, and should therefore be included in the process count just like any other. However, this is not very intuitive, because of the previously mentioned inconsistencies. The argument might also well be made that we're _never_ interested in the immediate ancestor of the plugin, and while it is unknown how many installations have already made the necessary modifications to their setups to make up for the fact that the plugin behaves the way it does, it is not deemed worthwhile to entertain such workarounds. Thus, this patch ignores the parent process. See also these bug reports: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=626913 http://sourceforge.net/p/nagiosplug/bugs/512/ https://github.com/nagios-plugins/nagios-plugins/issues/999 https://bugs.op5.com/view.php?id=4398
Diffstat (limited to 'ACKNOWLEDGEMENTS')
0 files changed, 0 insertions, 0 deletions