2

How can I make Apache kill the CGI's that it has spawned, after the client (browser) has closed the connection?

I got a couple of CGI's that perform long-running operations and send output every 15 seconds. As soon as the browser closes the connection, the CGI (and its descendants) should be properly killed instead of lingering around my system and keeping valuable Apache slots occupied.

Preferably Apache should kill them. If not, I would like to know if there is way for the CGI to detect whether the connection with the browser has gone away.

Edit: apparently, the CGI's will have their STDOUT closed. Upon writing, they'll get a SIGPIPE signal and could act accordingly (usually they ignore this signal). In Perl, you could do:

print "fresh output\n" or die "apparently my audience has left the building";

So the question remains: could Apache detect the broken pipe and clean up its garbage?

Running on Debian w/ Apache 2.2.20, and normal suexec mechanism.

Thanks!

Willem
  • 2,872
  • 4
  • 28
  • 35
  • This is done automatically and by default?! – mailq Oct 04 '11 at 22:49
  • mailq > atm, my server is unresponsive and a "ps uxaf" shows that all Apache procs have 1 cgi child. Stracing them shows that they are all in the waitpid() state. Perhaps I missed an Apache config directive somewhere? – Willem Oct 04 '11 at 22:55
  • Are you really running a CGI, or are you running something via mod_php, mod_perl, mod_python, etc. If you are really running a CGI, then the FastCGI module may have some timeouts you want. – Zoredache Oct 04 '11 at 23:02
  • Unfortunately it are CGI's that I don't have control over, I can only control the Apache server :( But thanks for the suggestion anyway! – Willem Oct 04 '11 at 23:05
  • 1
    Are there tons of CGIs like this? You could write a perl wrapper that you called from apache that watched and if the output was closed killed its exec of the actual CGI. I don't think Apache has something built-in to do this. – polynomial Oct 05 '11 at 03:03

0 Answers0