Note: this is the same as this SO post, but is possibly more appropriate here as I suspect the problem is server config related rather than code related.

I'm using a LAMP setup with PHP running through mod_fcgid. For most requests this works well, but I've noticed that when I download a file but interrupt the download before it's complete, the php-cgi process that was serving the file blocks attempting to write more data until it the IPCCommTimeout is reached. Once the timeout is reached, the process gets interrupted and the process starts servicing other requests again.

This problem does not occur if I use mod_php instead of mod_fcgid.

Is there some available setting for fcgid that I can set to have it abort if nothing is capturing the output? Is there something I can do in PHP to handle it?

The problem doesn't occur if the download isn't interrupted; in fact, I only noticed it because I was trying to stream a FLV file using gddflvplayer, which seems to send a brief request to get the first few frames (which it shows as a preview), then another to play it, and this causes the same problem.

FYI, this is the strace of the hanging cgi process; it sits like this until it's eventually interrupted, presumably by the process manager when the IPCCommTimeout is reached. My guess is that it's hanging trying to output the results of the readfile() call, but Apache is no longer listening (as the request has been cancelled by the user).

The logs indicate that the request is eventually reaped due to the timeout

mod_fcgid: read data timeout in 240 seconds

The download code more or less just uses readfile to serve up the file, with a few headers involved as well (note: in this code, Header is more or less just a wrapper around header() to avoid problems in tests).

3 Answers
3

We could see your problem as 'not really a problem', as when timeout occurs the php script ends. If it was not ending after the timeout you would get in bigger problems :-). Then to reduce the hangs time you would at least be able to play with the FcgidBusyTimeout & FcgidBusyScanInterval parameters, http://httpd.apache.org/mod_fcgid/mod/mod_fcgid.html#fcgidbusytimeout

The problem does resolve itself after the timeout, true, but it seems that fcgid doesn't realise that the cgi process is not responding and continues to send requests to it (at least, for the original browser that interrupted the download - not sure about others), which hang pending the timeout. So if I interrupt a download, then try to refresh the page, it will hang until the timeout occurs. If I open another browser and request a page, it works (and spans additional CGI processes as necessary).
–
El YoboJan 4 '11 at 9:42

you can as well check for apache way of detecting theses client breaks with netstat -nalp |grep ':80 '|grep "WAIT" . check if you have some FIN_WAIT_2 sockets for example. And check that you have a recent apache, to get all bugfixes. check "lingering close" here: httpd.apache.org/docs/2.2/misc/perf-tuning.html or that httpd.apache.org/docs/1.3/misc/fin_wait_2.html (older). if your problem comes from bad client close you can as well try to force your file upload in non-keepalive requests by setting the nokeepalive apache env variable for theses specific url.
–
regileroJan 4 '11 at 11:40

The problem comes down to PHP session locking; for some reason mod_php manages to unlock the session when the request is cancelled, but mod_fcgid doesn't in this case. Calling session_write_close() before readfile() (100% safe, as I'm not going to be doing anything after outputting the file anyway, as it would corrupt it) ensures the session lock is released and prevents the system hanging for that user.