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] [EMAIL PROTECTED] 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] [EMAIL PROTECTED] 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] [EMAIL PROTECTED] 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
