Bug 51030 - Way to terminate CGI immediatly after closing connection
Way to terminate CGI immediatly after closing connection
Status: NEW
Product: Apache httpd-2
Classification: Unclassified
Component: mod_cgi
2.5-HEAD
PC All
: P2 enhancement (vote)
: ---
Assigned To: Apache HTTPD Bugs Mailing List
:
Depends on:
Blocks:
  Show dependency tree
 
Reported: 2011-04-06 07:02 UTC by Maxim
Modified: 2011-04-08 07:55 UTC (History)
1 user (show)



Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Maxim 2011-04-06 07:02:47 UTC
As I understood there is only two mechanisms for CGI killing after colsing connection with client:
1. Waiting for Timeout seconds and sending CIGTERM to cgi process.
2. Waiting for SIGPIPE after cgi process trying to write to STDOUT.

There is no way to terminate long-thinking cgi-process while performing long-term queries to SQL. But there is no reason to wait for query finishing while client no more waiting for cgi response.
Comment 1 William A. Rowe Jr. 2011-04-06 13:21:34 UTC
And your proposed new way is ... ?
Comment 2 Maxim 2011-04-06 14:29:53 UTC
There is no need to wait until Timeout when connection is already closed. It is worth to send SIGTERM to cgi-process immediately after closing connection with client. Isn't it?
Comment 3 William A. Rowe Jr. 2011-04-08 01:49:10 UTC
So to summarize, you would suggest;

 1. send SIGTERM immediately

 2. after timeout, send SIGKILL

Is that what you are suggesting?

As it can be harmful to some applications, I can only foresee this being adopted as a per-dir (per specific <files > match) feature.  Also be aware that httpd may not be aware until httpd attempts to send data that the remote connection is AWOL, so this would be far from a perfect solution
Comment 4 Maxim 2011-04-08 05:49:49 UTC
(In reply to comment #3)
> So to summarize, you would suggest;
> 
>  1. send SIGTERM immediately
> 
>  2. after timeout, send SIGKILL
> 
> Is that what you are suggesting?
> 
> As it can be harmful to some applications, I can only foresee this being
> adopted as a per-dir (per specific <files > match) feature.  Also be aware that
> httpd may not be aware until httpd attempts to send data that the remote
> connection is AWOL, so this would be far from a perfect solution

Not exactly... I mean the only situations when you precisely know that client leave (by pressing 'cancel browsing', for example), consequently there is no need to wait untill Timeout (cause nobody waits cgi-script output), and it would be good to inform cgi-script somehow about this to force it stopping some hard job (cause no one need the results of it) or some other finishing. Why not perfect? In opposite it'll be very usefull. Of cause it should be configurable per-dir behaviour.
Comment 5 Joe Orton 2011-04-08 07:55:08 UTC
This is not possible without completely redesigning the filter architecture; you need to poll across all of (socket, CGI stdout, CGI stderr) to be able to detect the TCP connnection closure from the client.  i.e. RESOLVED->WONTFIX.