#36158 [Asn]: SIGTERM is not handled correctly when running as a FastCGI server
| From: | chris at mysociety dot org | Date: | Wed, 01 Feb 2006 23:48:51 +0000 |
| Subject: | #36158 [Asn]: SIGTERM is not handled correctly when running as a FastCGI server | ||
| References: | 1 | Groups: | php.bugs |
| Request: | Send a blank email to php-bugs+get-92808@lists.php.net to get a copy of this message | ||
ID: 36158
User updated by: chris at mysociety dot org
Reported By: chris at mysociety dot org
Status: Assigned
Bug Type: CGI related
Operating System: *
PHP Version: 5.1.2, 4.4.2
Assigned To: dmitry
New Comment:
Yeah, that's a fair point. Matters would be improved by adding the
FCGI_FAIL_ON_INTR flag to the call to FCGX_InitRequest; that's not a
complete solution, since that might cause the server process to quit on
receipt of another signal in the call to FCGX_Accept_r, but that's not a
very serious problem. Here's a patch that includes that change:
http://bitter.ukcod.org.uk/~chris/tmp/20060201/php-4.3.10-fastcgi-sigterm-fix.patch
Previous Comments:
------------------------------------------------------------------------
[2006-02-01 18:20:43] stefan at luli dot de
Hi there,
I am struggeling with the described problem for quite some time now. I
have traced the problem now in the code back to
the SIGTERM play between fcgi_pm and php.
The question is if fcgi_pm should send a SIGTERM to the script even
though it processes a request at this momment. One would think that
fcgi_pm should be smart enough to deal with this situation (wait until
request is done/send no more requests/send SIGTERM). But apparently it
isn't.
The patch seams to do the trick, but is also prevents php to terminate
in case it's just idel. So php will sit there until the next request
comes in and terminate once the request is done before waiting for the
next request to come in. This should be solved.
------------------------------------------------------------------------
[2006-01-26 08:58:25] sniper@php.net
Dmitry, does the new code fix this problem..?
------------------------------------------------------------------------
[2006-01-26 01:55:15] chris at mysociety dot org
That snapshot (a) doesn't fix the problem -- the FastCGI code is
essentially unchanged since 4.x, though with a bunch of whitespace
noise; and (b) wouldn't help us in any case since it's PHP5 and our
applications are written for PHP4.
------------------------------------------------------------------------
[2006-01-25 23:51:05] sniper@php.net
Please try using this CVS snapshot:
http://snaps.php.net/php5.1-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.1-win32-latest.zip
------------------------------------------------------------------------
[2006-01-25 21:00:06] chris at mysociety dot org
Description:
------------
When php is running as a FastCGI server, it should handle SIGTERM and
execute a graceful shutdown, because the mod_fastcgi process manager
uses this signal to shut down excess dynamic servers. "Graceful" in
this context means that the server must finish handling any outstanding
request and then terminate its connection to the web server. Presently,
PHP does not handle SIGTERM at all in the FastCGI request loop, so that
on receipt of SIGTERM, php aborts, even if half-way through a request.
This typically results in the web server logging "Incomplete headers (0
bytes) received", and returning "500 Internal Server Error" to the
client.
I have prepared a patch for this issue, here:
http://bitter.ukcod.org.uk/~chris/tmp/20060125/php-4.3.10-fastcgi-sigterm-fix.patch
-- this is against 4.3.10, but it applies to 4.4.2 fine.
Reproduce code:
---------------
Put the following in a .php file:
<? sleep(1); print "fish"; ?>
and set it up to run under FastCGI. Set up a script to request the page
in a loop ("while : ; do wget -O/dev/null -q http://path/to/script ;
done") Then kill the PHP process (pkill php will do this under Linux).
If you catch the script in the sleep, this will result in the client
getting a 500 and the web server logging a message about php failing,
as describe above.
Expected result:
----------------
No errors.
Actual result:
--------------
500 error.
------------------------------------------------------------------------
--
Edit this bug report at http://bugs.php.net/?id=36158&edit=1