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]

help needed with froked process becoming zombies


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]