DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23911>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23911 CGI processes left defunct/zombie under 2.0.47 ------- Additional Comments From [EMAIL PROTECTED] 2003-11-07 18:27 ------- I don't know what the next step is, unfortunately. I've been testing 2.0.47 with default config (prefork, mod_cgi, no suexec) this afternoon and using printenv as the example cgi. No long-term zombies. printenv goes through zombie state temporarily but Apache cleans it up very soon after. I'm curious about how you can tell it isn't specific to some cgi. All I see from ps for zombies is trawick 6872 29703 0 0:00 <defunct> Is it possible that the zombie represents a child process that the CGI script created, and not the CGI script itself? Apache parent -> Apache child process -> CGI script -> some command invoked by the CGI Maybe there is some infrequent condition where the Apache child process terminates the CGI script before it has reaped status from the command it runs, and then the Apache child process becomes the parent of the command invoked by the CGI. Since the Apache child process doesn't call waitpid() to collect status from arbitrary processes, then the zombie never gets cleaned up. Apache will terminate the CGI script with SIGTERM (and later SIGKILL) if the CGI script keeps running for a while after the client connection drops. >Is there something I can do once I get zombies? nothing easy that I know of... --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
