> -----Ursprüngliche Nachricht----- > Von: Joe Orton > Gesendet: Dienstag, 24. Oktober 2006 19:46 > An: [email protected] > Betreff: Re: cgi: KILL_AFTER_TIMEOUT vs KILL_ALWAYS > > > On Tue, Oct 24, 2006 at 09:38:07AM -0700, Paul Querna wrote: > > Currently, mod_cgi{d} sets APR_KILL_AFTER_TIMEOUT. It > appears however, > > on a server under high load (>100 load average), it is > possible for only > > the initial SIGTERM to be sent. It appears that the > SIGKILL was never > > sent to the child CGI processes.
mod_cgid or mod_cgi? > > > > I believe that the parent process, which is supposed to > have a 7 second > > space between its own SIGTERM and SIGKILL, is getting the > SIGKILL before > > it has slept for 3 seconds *and* sent the final SIGKILL to > the child > > CGIs. This has the potential to leave broken child > processes behind. > > "apachectl stop" never SIGKILLs the parent though, are you using init > scripts for this really? We had exactly that problem in the But the parent httpd process sents SIGKILL to its child processes after a timeout, correct? And the cgi's are childs of the httpd childs. > Fedora/RHEL > httpd init script, the fix was to adjust the delay used to ensure the > normal httpd parent shutdown can take place before any > SIGKILL is sent. > > > Is there anything seriously wrong with using SIGKILL first? > > It's impolite :) Really, it could propagate the problem: if > the CGI has > spawned any subprocesses or created temp files or anything > like that, it > doesn't get the chance to clean them up. Why do the cgi's don't die when they get a SIGTERM. In this case I suppose that there is something wrong with the cgi's. SIGKILL seems to be the last resort for me if the process does not respond to SIGTERM. Regards Rüdiger
