|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #41593 FastCGI does not handle graceful reload/shutdown
Submitted: 2007-06-04 23:06 UTC Modified: 2007-12-18 01:00 UTC
Avg. Score:4.8 ± 0.5
Reproduced:24 of 24 (100.0%)
Same Version:8 (33.3%)
Same OS:19 (79.2%)
From: jonepet at dcvhost dot no Assigned: dmitry (profile)
Status: No Feedback Package: CGI/CLI related
PHP Version: 5.2.3 OS: Linux
Private report: No CVE-ID: None
View Add Comment Developer Edit
Anyone can comment on a bug. Have a simpler test case? Does it work for you on a different platform? Let us know!
Just going to say 'Me too!'? Don't clutter the database with that please — but make sure to vote on the bug!
Your email address:
Solve the problem:
49 + 22 = ?
Subscribe to this entry?

 [2007-06-04 23:06 UTC] jonepet at dcvhost dot no
This is a duplicate of older closed Bug #36158. Solved in previous version, but broken again in newer (because of replaced lib?).

The FastCGI module in PHP does not handle graceful/SIGTERM shutdown/reload correctly. When sending a graceful reload to Apache, all running PHP processes dies, and Apache return "500 Internal Server Error" to waiting HTTP clients.

Reproduce code:
  echo "Done";

Open in a web browser and then do an apache2ctl graceful on the server.

Expected result:
"Done" should be printed to the web browser after 10 seconds.

Actual result:
"Internal Server Error" to browser and "premature end of script headers" to log file.


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2007-06-05 07:34 UTC]
In what PHP version did it work?
 [2007-06-05 07:58 UTC] jonepet at dcvhost dot no
As of the close/last comment of Bug #36158 it was working at that time. I don't know if it really did, or if there was any releases with this fix.

I didn't meant "previous version" but "earlier version", in the original description, referring to the last comment of Bug #36158.
 [2007-06-12 19:31 UTC] severn-php at xephris dot net
From the looks of the changelog, Bug #36158 was fixed in 5.1.3

I just tried that with mod_fcgid 2.1 and Apache 2.2.4 on x64 Linux and it too "died". mod_fcgid sends SIGTERM to the PHP process which dies returning a blank page. I also tried it with mod_fastcgi 2.4.2 and Apache 1.3.37, that died with the 500 error.

I've also tried PHP 5.1.6 and 5.2.3, same issue.

So... it looks to me like the bug was never actually fixed... (not in 5.x at least). I get the same behaviour with 4.4.7 (blank screen with mod_fcgid, 500 error with mod_fastcgi)
 [2007-06-13 17:40 UTC]
PHP/fastcgi catches SIGTERM and always does graceful shutdown, however mod_fcgid sends SIGTERM then waits for one second and sends SIGKILL if PHP process isn't exited.

So this is not a PHP issue.
 [2007-06-13 19:25 UTC] severn-php at xephris dot net
Re: mod_fcgid: I see... I guess I'll modify mod_fcgid myself for that setup.

That doesn't explain the mod_fastcgi problems though. I thought it might be something with my setup so I rebuilt it from scratch... might have had some old crap left behind. I don't get 500 errors with PHP 5.2.3 + mod_fastcgi 2.4.2 + Apache 1.3.37 anymore, so it does look fixed in 5.2.3... but I get another strange problem: doing a graceful restart shortens the sleep time to zero. i.e.

 $a = time();
 echo time()-$a;

Going to this page then doing a graceful after 5 seconds would give "5" instead of the expected "30".

exec /opt/php5/bin/php-cgi $*

For the record, PHP 4.4.7 dies with a 500 error, but that's not a big problem for us...

Could the OP perhaps provide us some info on what versions of Apache and mod_fastcgi/mod_fcgid so we can try replicating it?
 [2007-10-16 20:48 UTC] andrei dot nigmatulin at gmail dot com
Graceful reload/shutdown implemented in unofficial patch For now docs are in Russian, though.
 [2007-11-19 18:56 UTC]
This is still buggy.
 [2007-12-10 16:15 UTC]
I'm not able to reproduce the HTTP 500 response  on graceful restart with PHP_5_3, mod_fastcgi and Apache.
 [2007-12-18 01:00 UTC] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
 [2008-02-15 21:59 UTC] dan at sypher7 dot com
I was able to reproduce this in the 4.4.8 version of PHP using the latest mod_fastcgi and Apache 1.3.

From what I understand, a graceful reload sends a SIGUSR1 to Apache. The  FastCGI processor manager then sends SIGTERMs to all of the running processes.

Instead of exiting cleanly, the PHP script ends abruptly and doesn't even finish sending headers. Here is what Apache's log had to say about it:

 FastCGI: incomplete headers (0 bytes) received from server "/path/to/php-fcgi-wrapper"

I've tried messing with the FastCgiConfig settings a lot, but nothing in there appears to be changing the result.

I do not know either codebase well, so I can't say with certainty if this is a mod_fastcgi or PHP bug. It would appear that either PHP isn't closing out cleanly on a SIGTERM or mod_fastcgi isn't waiting around for the process to end.
 [2008-02-18 19:13 UTC] dan at sypher7 dot com
I just wanted to follow up:

I recently installed PHP 5.2.5 alongside 4.4.8. With the identical setup. PHP4 will cause the internal server error, but PHP5 will not. So this appears to be a PHP4-only issue.
 [2008-02-26 08:48 UTC] marekm at apnet dot pl
I can confirm that the same problem happens with Apache 2.2.8 + mod_fastcgi 2.4.6 + PHP 5.2.5 ie. graceful restarts always cause error 500. This is absolutely repeatable.
 [2008-02-27 22:29 UTC] dan at sypher7 dot com
I previously reported that this issue was only effecting PHP4 and not PHP5. I've now seen PHP 5.2.5 throw 500 errors as well (using mod_fastcgi).

I believe there are actually two different bugs here. One of them is with PHP 4.4.8. That bug is that fastcgi mode PHP does not clean up and exit properly (send headers, etc.) on a SIGTERM from the fastcgi process manager. It simply dies and returns no headers resulting in the 500 error in Apache. This is incorrect cleanup on the part of PHP.

Doing some further digging, there appear to be indications that the fastcgi process manager will send a SIGKILL after a SIGTERM if the process doesn't finish sufficiently fast. Although I did see comments indicating this in the mod_fastcgi code, and corresponding code that would do that on Win32 platforms, I could not find in the source code that mod_fastcgi's process manager would actually do this for a *nix platform, so I'm unsure if this is actually happening.

In any case, the problem with PHP5 throwing the 500 errors seems to be that it is getting a SIGKILL from someone (either Apache or mod_fastcgi), which isn't really a PHP bug, but something to be looked into with either apache or the fastcgi people. I'm investigating that, but the issues with PHP4 still stand.
 [2008-03-24 11:41 UTC] void at voip dot e-burg dot ru
PHP 5.2.6RC1
i run php-cgi directly from initng and have term_timeout = 80,
ei initng suspends SIGKILL for 80sec after SIGTERM

when i sigterm php-cgi, i get this fom my web server (lighttpd):
 (mod_fastcgi.c.2462) unexpected end-of-file (perhaps the fastcgi process died): pid: 0 socket: tcp:
 (mod_fastcgi.c.3254) response not received, request sent: 1538 on socket: tcp: for /index.php , closing connection

it seems php even not try to shutdown gracefuly
 [2008-04-06 15:39 UTC] hanno at hboeck dot de
Bernd Wurst has written a workaround-patch for fastcgi, which can be found here:

Maybe some more skilled programmers want to comment on it.
 [2008-06-02 10:17 UTC] stephan dot jaeger at ewetel dot de
The mod_fastcgi patch above works with PHP5 (5.2.3 here). But PHP 4 does not have a signal handler for SIGTERM, so it exits immediatly without finishing the current request and still gives a 500. Adding a signal handler for SIGTERM seems to solve this problem:

--- os_unix.c.orig	2008-06-02 11:29:25.000000000 +0200
+++ os_unix.c	2008-06-02 11:29:46.000000000 +0200
@@ -147,6 +147,7 @@
     sa.sa_handler = OS_Sigusr1Handler;
     installSignalHandler(SIGUSR1, &sa, force);
+    installSignalHandler(SIGTERM, &sa, force);
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Fri Jun 21 15:01:29 2024 UTC