This is the mail archive of the libc-help@sourceware.org mailing list for the glibc project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
Hey. So,... the website says "No question about glibc is ever wrong on this list." about this list... and I hope asking about process control and that like isn't too off topic. Perhaps someone can help us here with quite some problem, appearing in Nagios and Icinga on. What happens for both is, that external programs are executed at defined intervals (via fork followed by either execvp or popen). The output of the command is then collected and processed. There are also some sig handlers installed, that kill the plugin after a certain timeout (in case they go mad or so). Now usually all this goes quite well, unless the executed check forks itself. In that case the original check process completes but is then (maybe) not correctly reaped... until it runs into the aforementioned timeout (which is quite bad as this is considered an error state). The forked copy continues to live. Some of the Icinga experts (the Nagios code is largely the same in that area) already tried to find the reason, but without success. If there some expert around who could help out and have a look, that would be great. The issue is traced in the following bug reports: https://dev.icinga.org/issues/2546 http://tracker.nagios.org/view.php?id=321 Michael Friedrich from Icinga made some comments (https://dev.icinga.org/issues/2546#note-26) on where to look best for the respective code areas. All happens basically in the run_async_service_check() function within base/checks.c If I can do anything to help, just tell! Thanks, Chris.
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |