php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #24167 [PATCH] FastCGI server processes dying when script not found
Submitted: 2003-06-13 03:14 UTC Modified: 2003-08-05 17:09 UTC
Votes:1
Avg. Score:5.0 ± 0.0
Reproduced:1 of 1 (100.0%)
Same Version:1 (100.0%)
Same OS:0 (0.0%)
From: mweilguni at sime dot com Assigned: shane (profile)
Status: Closed Package: CGI/CLI related
PHP Version: 4.3.2 OS: Redhat Linux 7.2
Private report: No CVE-ID: None
View Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
If you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: mweilguni at sime dot com
New email:
PHP Version: OS:

 

 [2003-06-13 03:14 UTC] mweilguni at sime dot com
Description:
------------
We use PHP 4.3.2 + FastCGI + Apache/mod_fcgi. The PHP fastcgi server is started in our setup with 8 preforked php-servers,
so after a restart the process tree will look like:
\_ /usr/bin/php-fcgi-4.3.2
   |   \_ /usr/bin/php-fcgi-4.3.2
   |   \_ /usr/bin/php-fcgi-4.3.2
   |   \_ /usr/bin/php-fcgi-4.3.2
   |   \_ /usr/bin/php-fcgi-4.3.2
   |   \_ /usr/bin/php-fcgi-4.3.2
   |   \_ /usr/bin/php-fcgi-4.3.2
   |   \_ /usr/bin/php-fcgi-4.3.2
   |   \_ /usr/bin/php-fcgi-4.3.2

so far it's ok. when I request for a non-existant script, I get the error "No input file specified.". That's ok too. But after that, one server process died:
\_ /usr/bin/php-fcgi-4.3.2
   |   \_ /usr/bin/php-fcgi-4.3.2
   |   \_ /usr/bin/php-fcgi-4.3.2
   |   \_ /usr/bin/php-fcgi-4.3.2
   |   \_ /usr/bin/php-fcgi-4.3.2
   |   \_ /usr/bin/php-fcgi-4.3.2
   |   \_ /usr/bin/php-fcgi-4.3.2
   |   \_ /usr/bin/php-fcgi-4.3.2

After requesting a non-existant script 8 times all servers are gone, only the master server process remains:
\_ /usr/bin/php-fcgi-4.3.2

I checked the file sapi/cgi/cgi_main.c and it seems the error is in line 1473:
        if (retval == FAILURE && file_handle.handle.fp == NULL) {
            SG(sapi_headers).http_response_code = 404;
            PUTS("No input file specified.\n");
            php_request_shutdown((void *) 0);
            php_module_shutdown(TSRMLS_C);
            return FAILURE;
        }

IMO this should be:
        if (retval == FAILURE && file_handle.handle.fp == NULL) {
            SG(sapi_headers).http_response_code = 404;
            PUTS("No input file specified.\n");
#if PHP_FASTCGI
            continue; 
#endif
            php_request_shutdown((void *) 0);
            php_module_shutdown(TSRMLS_C);
            return FAILURE;
        }

It seems to work fine, but I'm not really sure if this is right.


Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2003-06-13 07:46 UTC] sniper@php.net
Shane should know? :)

 [2003-06-18 10:29 UTC] iliaa@php.net
Try this patch http://bb.prohost.org/fcgi.txt and let me know if it fixes the problem.
 [2003-06-29 15:07 UTC] shane@php.net
Please do not submit the same bug more than once. An existing
bug report already describes this very problem. Even if you feel
that your issue is somewhat different, the resolution is likely
to be the same. Because of this, we hope you add your comments
to the existing bug instead.

Thank you for your interest in PHP.

this is a dup of 24009, patch being submitted shortly
 [2003-06-29 18:16 UTC] sniper@php.net
Fixed. See bug #24009.

 [2003-07-03 04:11 UTC] mweilguni at sime dot com
The bug is not really fixed. The request now works (I get "No input file specified"), but the affected server process still terminates and after 8 such requests alle servers are gone. What's the reason to terminate the request if no input file was found?
 [2003-07-03 05:16 UTC] sniper@php.net
Shane, take a look?

 [2003-08-05 17:09 UTC] iliaa@php.net
This bug has been fixed in CVS.

In case this was a PHP problem, snapshots of the sources are packaged
every three hours; this change will be in the next snapshot. You can
grab the snapshot at http://snaps.php.net/.
 
In case this was a documentation problem, the fix will show up soon at
http://www.php.net/manual/.

In case this was a PHP.net website problem, the change will show
up on the PHP.net site and on the mirror sites in short time.
 
Thank you for the report, and for helping us make PHP better.

Cannot replicate the problem using the latest snapshot.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Fri Dec 27 00:01:30 2024 UTC