#43173 [Fbk->Opn]: FastCGI Broken due to session file - Redux
| From: | davidb at chelsea dot net | Date: | Thu, 15 Nov 2007 23:28:26 +0000 |
| Subject: | #43173 [Fbk->Opn]: FastCGI Broken due to session file - Redux | ||
| References: | 1 | Groups: | php.bugs |
| Request: | Send a blank email to php-bugs+get-119709@lists.php.net to get a copy of this message | ||
ID: 43173
User updated by: davidb at chelsea dot net
Reported By: davidb at chelsea dot net
-Status: Feedback
+Status: Open
Bug Type: CGI related
Operating System: Solaris 2.8
PHP Version: 5.2.4
Assigned To: dmitry
New Comment:
I am absolutely, 100% certain that I'm using the right binary. I've
gone back and forth multiple times, and it is reproducible. Since this
is for http://www.fastcgi.com, I have added incentive to get
it figured
out.
How can I help troubleshoot this? How does php decide if it's running
as a CGI or a FastCGI? How did that part of the code change? I'm not a
C coder unfortunately (limited read-only knowledge) but from the truss()
I'm guessing that the check is failing and it's using the cgi interfaces
instead of the fastcgi interface when it wakes up.
The web server is running as follows:
- apache 1.3.39
- mod_fastcgi (previous versions, and also tried latest release of a
few days ago to see if it makes a difference)
- Using the php proc manager to control children, NOT the apache
procmanager (this is the default mode of operation, or at least it was)
- The only environment variable is PHP_FCGI_CHILDREN=2
- suexec is spawning this
As I mentioned before, I have an identical configuration for 5.2.0 and
it works fine.
Thanks.
Previous Comments:
------------------------------------------------------------------------
[2007-11-15 22:53:06] jani@php.net
Are you sure you're loading the right php binary in your apache conf?
I can't reproduce this, everything works just fine (although I'm using
lighttpd..:)
------------------------------------------------------------------------
[2007-11-15 14:02:38] davidb at chelsea dot net
Greetings.
I provided this input (or at least, I could swear I did). Here it is
again. I feel like a bit of a broken record, as this is clearly related
to the major FastCGI work that was done in 5.2.1'ish.
Here's the output:
<tr><td class="e">Server API </td><td
class="v">CGI/FastCGI
</td></tr>
The run_configure is IDENTICAL for 5.2.0 and 5.2.4.
Also, please note that php doesn't seem to be figuring out it's running
as a FastCGI application.
Please let me know if there's anything else I can do to help debug
this.
------------------------------------------------------------------------
[2007-11-01 17:47:13] dmitry@php.net
Was your php compiled with --enable-fastcgi?
Try the following command:
$ sapi/cgi/php-cgi -i | grep "Server API"
Do you see CGI/FastCGI?
------------------------------------------------------------------------
[2007-11-01 17:35:43] jani@php.net
Dmitry, you know it best. :)
------------------------------------------------------------------------
[2007-11-01 13:43:51] davidb at chelsea dot net
Description:
------------
I don't seem to be able to reopen the previous bug, #43086, as it was
marked "bogus".
Unfortunately, while this fixed the problem of the semaphore behavior
change, it still didn't work. When php tries to read from the socket
now, it gets an invalid descriptor:
17997: read(0, 0x007BBA0C, 8192) Err#134
ENOTCONN
It actually looks like it's not behaving as the proc manager, but
behaving as a regular PHP client. I note that the working php version
of 5.2.0 goes into an accept() instead of a read:
18364: fcntl(0, F_SETLKW, 0xFFBEDA38) (sleeping...)
Which is the correct behavior.
Are there configuration changes that were made that I've missed in the
documentation affecting the default behavior under FastCGI? Is it not
detecting that it should be running in FastCGI mode right now?
The run_configure, build, and Apache environment for 5.2.0 and 5.2.4
are identical, so something has changed in the PHP code. Please advise.
------------------------------------------------------------------------
--
Edit this bug report at http://bugs.php.net/?id=43173&edit=1