ID: 41593 Comment by: hanno at hboeck dot de Reported By: jonepet at dcvhost dot no Status: No Feedback Bug Type: CGI related Operating System: Linux PHP Version: 5.2.3 Assigned To: dmitry New Comment:
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. Previous Comments: ------------------------------------------------------------------------ [2008-03-24 11:41:27] 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: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 ------------------------------------------------------------------------ [2008-02-27 22:29:22] 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-02-26 08:48:08] 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-18 19:13:22] 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-15 21:59:49] 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. ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/41593 -- Edit this bug report at http://bugs.php.net/?id=41593&edit=1
