You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@httpd.apache.org by dan kelley <dk...@otec.com> on 2002/01/29 16:52:28 UTC
mod_cgi kills CGI subprocesses after 3 seconds
hi-
i'm having some difficulty with CGI subprocess being killed by apache
shortly after they close stdout. we have some CGI programs that continue
to do background processing after they've finished returing data to the
client, so it would be beneficial to us to be able to change this
behavior.
it looks like mod_cgi.c defaults to sending subprocesses SIGTERM
immediately after the subprocess closes stdout, then SIGKILL 3 seconds
later:
from mod_cgi.c:
if (!ap_bspawn_child(r->main ? r->main->pool : r->pool, cgi_child,
(void *) &cld, kill_after_timeout,
&script_out, &script_in, &script_err))
from ap_alloc.h:
enum kill_conditions {
kill_never, /* process is never sent any signals */
kill_always, /* process is sent SIGKILL on pool cleanup */
kill_after_timeout, /* SIGTERM, wait 3 seconds, SIGKILL */
just_wait, /* wait forever for the process to complete */
kill_only_once /* send SIGTERM and then wait */
};
it looks like we could change the behavior of mod_cgi to better fit what
we need to do by simply changing the 4th arg of ap_bspawn_child in
mod_cgi.c from kill_after_timeout to kill_never.
question: is there currently any way to do this with a config directive?
i've looked through the FAQ, the CGI docs, and a mail archive, but didn't
find anything that suggested such a config directive existed. if there
isin't, would there be any obvious disadvantage to implementing one?
thanks-
dan
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: mod_cgi kills CGI subprocesses after 3 seconds
Posted by Martin Haase-Thomas <mh...@meome-ag.de>.
sounds like a case for mod_perl - and maybe one additional process
started by the first apache process that will do everything for the
welfare of your dying scripts.
dan kelley wrote:
>>>i'm having some difficulty with CGI subprocess being killed by apache
>>>shortly after they close stdout. we have some CGI programs that continue
>>>to do background processing after they've finished returing data to the
>>>client, so it would be beneficial to us to be able to change this
>>>behavior.
>>>
>>I'm not an expert in this area, but if you read the CGI FAQs, they will tell
>>you that the correct way to do long-lived processing from a CGI is to fork a
>>subprocess from your cgi script and make sure that the subprocesses closes
>>stdin, stdout, and stderr.
>>
>
>ok, but there are several problems with this approach :
>
> 1. the extra fork: adds complexity to my CGIs, hurts performance
> 2. i only need (on average) 2-3 seconds of CPU time for the extra
> processing.
>
>to explain the problem further: all of these CGIs originally ran under
>Netscape Enterprise; the default behavior of NES was to let them run
>forever, so we already have code in a CGI lib that sets a timeout to kill
>runaway CGIs. right now, we're prevented from using apache because
>there's no clean way to stop apache from killing the CGIs once they close
>stdout.
>
>thanks-
>
>dan
>
>
>---------------------------------------------------------------------
>The official User-To-User support forum of the Apache HTTP Server Project.
>See <URL:http://httpd.apache.org/userslist.html> for more info.
>To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
>For additional commands, e-mail: users-help@httpd.apache.org
>
>
Re: mod_cgi kills CGI subprocesses after 3 seconds
Posted by dan kelley <dk...@otec.com>.
> > > From: dan kelley [mailto:dkelley@otec.com]
> >
> > > there's no clean way to stop apache from killing the CGIs once they close
> > > stdout.
>
> That's a bit like saying "... there's no clean way to let one process
> hang the kernel in linux." ;-)
>
> My point being, I think you might be missing one of apache's greatest
> strengths - its ability to allow users to execute CGI programs without
> risk of damaging the system. With apache, I've never seen memory leaks,
> zombie processes (well - maybe once) or had to frequently restart the
> server (ask anyone who maintains a IIS server - daily *reboots* are
> required...). It achieves this largely through the child-server approach
> whereby a host of children are spawned, allowed to serve a limited
> number of requests, then die. In a sense, your apache server has always
> just recently started.
i understand what you're getting at (especially as one who has to maintain
several IIS servers). i do think the greatest benefit is provided to
server admins that are going to run a diverse number of CGI scripts (i'm
thinking of hosting cos).
> I don't know what is wrong with forking a child if you need to finish
> off some post-processing - it seems a lot less bother than tracking down
> errant CGIs and squishing them. Frankly I'd not sleep at night knowing
> that undead CGIs were whirring away on my server... gobbling up
> memory... blocking ports...
that's not an issue for us - every CGI that runs on the system initializes
itself by (among other things) requesting a SIGTERM, then a SIGKILL
(exactly the same behavior as apache) after a certain period of time. i'm
not looking to throw away this safety net - i just want to be able to
paramaterize it to fit a particular purpose.
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: mod_cgi kills CGI subprocesses after 3 seconds
Posted by Owen Boyle <ob...@bourse.ch>.
> > From: dan kelley [mailto:dkelley@otec.com]
>
> > there's no clean way to stop apache from killing the CGIs once they close
> > stdout.
That's a bit like saying "... there's no clean way to let one process
hang the kernel in linux." ;-)
My point being, I think you might be missing one of apache's greatest
strengths - its ability to allow users to execute CGI programs without
risk of damaging the system. With apache, I've never seen memory leaks,
zombie processes (well - maybe once) or had to frequently restart the
server (ask anyone who maintains a IIS server - daily *reboots* are
required...). It achieves this largely through the child-server approach
whereby a host of children are spawned, allowed to serve a limited
number of requests, then die. In a sense, your apache server has always
just recently started.
I don't know what is wrong with forking a child if you need to finish
off some post-processing - it seems a lot less bother than tracking down
errant CGIs and squishing them. Frankly I'd not sleep at night knowing
that undead CGIs were whirring away on my server... gobbling up
memory... blocking ports...
Rgds,
Owen Boyle.
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
RE: mod_cgi kills CGI subprocesses after 3 seconds
Posted by Joshua Slive <jo...@slive.ca>.
> From: dan kelley [mailto:dkelley@otec.com]
> ok, but there are several problems with this approach :
>
> 1. the extra fork: adds complexity to my CGIs, hurts performance
> 2. i only need (on average) 2-3 seconds of CPU time for the extra
> processing.
>
> to explain the problem further: all of these CGIs originally ran under
> Netscape Enterprise; the default behavior of NES was to let them run
> forever, so we already have code in a CGI lib that sets a timeout to kill
> runaway CGIs. right now, we're prevented from using apache because
> there's no clean way to stop apache from killing the CGIs once they close
> stdout.
So you are trying to duplicate stupid netscape behaviour? Well, feel free
to hack mod_cgi if you'd like. I'm not sure what other solution you are
expecting. Apache's behaviour seems entirely correct and consistent.
Joshua.
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
RE: mod_cgi kills CGI subprocesses after 3 seconds
Posted by dan kelley <dk...@otec.com>.
> > i'm having some difficulty with CGI subprocess being killed by apache
> > shortly after they close stdout. we have some CGI programs that continue
> > to do background processing after they've finished returing data to the
> > client, so it would be beneficial to us to be able to change this
> > behavior.
>
> I'm not an expert in this area, but if you read the CGI FAQs, they will tell
> you that the correct way to do long-lived processing from a CGI is to fork a
> subprocess from your cgi script and make sure that the subprocesses closes
> stdin, stdout, and stderr.
ok, but there are several problems with this approach :
1. the extra fork: adds complexity to my CGIs, hurts performance
2. i only need (on average) 2-3 seconds of CPU time for the extra
processing.
to explain the problem further: all of these CGIs originally ran under
Netscape Enterprise; the default behavior of NES was to let them run
forever, so we already have code in a CGI lib that sets a timeout to kill
runaway CGIs. right now, we're prevented from using apache because
there's no clean way to stop apache from killing the CGIs once they close
stdout.
thanks-
dan
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
RE: mod_cgi kills CGI subprocesses after 3 seconds
Posted by Joshua Slive <jo...@slive.ca>.
> From: dan kelley [mailto:dkelley@otec.com]
> i'm having some difficulty with CGI subprocess being killed by apache
> shortly after they close stdout. we have some CGI programs that continue
> to do background processing after they've finished returing data to the
> client, so it would be beneficial to us to be able to change this
> behavior.
I'm not an expert in this area, but if you read the CGI FAQs, they will tell
you that the correct way to do long-lived processing from a CGI is to fork a
subprocess from your cgi script and make sure that the subprocesses closes
stdin, stdout, and stderr.
Joshua.
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org