In what PHP version did it work?

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.

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)

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.

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.

<?php
 $a = time();
 sleep(30);
 echo time()-$a;
?>

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

php5.fcgi==
#!/bin/sh
export PHP_FCGI_CHILDREN=4
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?

Graceful reload/shutdown implemented in unofficial patch http://php-fpm.anight.org/. For now docs are in Russian, though.

This is still buggy.

I'm not able to reproduce the HTTP 500 response  on graceful restart with PHP_5_3, mod_fastcgi and Apache.

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".

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.

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.

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.

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.

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:172.31.2.108:1026
 (mod_fastcgi.c.3254) response not received, request sent: 1538 on socket: tcp:172.31.2.108:1026 for /index.php , closing connection

it seems php even not try to shutdown gracefuly

Bernd Wurst has written a workaround-patch for fastcgi, which can be found here:
http://svn.schokokeks.org/repos/overlay/trunk/www-apache/mod_fastcgi/files/fcgi_pm.c.diff

Maybe some more skilled programmers want to comment on it.

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);
 }
 
 /*