|
|
php.net | support | documentation | report a bug | advanced search | search howto | statistics | random bug | login |
[2007-11-01 13:43 UTC] 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. PatchesPull RequestsHistoryAllCommentsChangesGit/SVN commits
|
|||||||||||||||||||||||||||||||||
Copyright © 2001-2025 The PHP GroupAll rights reserved. |
Last updated: Mon Oct 27 13:00:01 2025 UTC |
PHP under apache uses it's own process manager to spawn children. I believe you can disable that so Apache does it itself, but I prefer to manage it in PHP so we can control the number of PHP works without editing httpd.conf. Here's the relevant configuration. In httpd.conf, I set up the PHP server as follows: AddHandler php-fastcgi .php <Location /cgi-bin/php> SetHandler fastcgi-script </Location> Action php-fastcgi /cgi-bin/php DirectoryIndex index.html index.shtml index.php AddType application/x-httpd-php .php FastCgiServer /export/httpd/DOMAINS/fastcgi.com/cgi-bin/php -processes 1 The FastCgiServer is a shell script that execs the PHP process. We use it to set shell variables that we might need: #!/bin/sh PHP_FCGI_CHILDREN=2 export PHP_FCGI_CHILDREN exec /usr/local/bin/php5 All of this has worked fine for PHP 4.X, 5.0.X, 5.1.X, and 5.2.0. It broke sometime after 5.2.0. David.Greetings. I don't know how else to convince everyone that I'm using the right file. But, here goes: - I run the EXACT SAME CONFIGURE SCRIPT for 5.2.0 and 5.2.4. It looks like this: ./configure --prefix=/opt/php/5.2.4 \ --with-zlib=/usr/local \ --with-mysql=/usr/local \ --with-db4=/usr/local \ --with-config-file-path=/usr/local/etc/php \ --enable-gd-native-ttf \ --with-jpeg-dir=/usr/local \ --with-openssl=/usr/local \ --with-gd=/usr/local \ --with-png-dir=/usr/local \ --with-freetype-dir=/usr/local \ --with-mhash=/usr/local \ --with-mm=/usr/local \ --with-xsl=/usr/local \ --with-zend-vm=CALL \ --with-curl=/usr/local \ --with-imap=/usr/local \ --with-imap-ssl=/usr/local \ --with-libxml-dir=/usr/local \ --enable-spl \ --enable-calendar \ --enable-fastcgi \ --enable-force-cgi-redirect \ --enable-sockets \ --enable-mbstring You'll know the first line allows us to change the directory that we build in so we can test new versions. - /usr/local/bin/php5 is a symlink pointing to the currently active version on the test machine. We also sometimes exec /opt/php/5.2.4/bin/php directly, there's no difference in failure type. - 5.2.0 works without a problem (as to 5.0.3 and 4.X); 5.2.3 and 5.2.4 do not. - Here's the output of ls -l: -rwxr-xr-x 1 root other 39685444 Aug 12 08:34 /opt/php/5.2.0/bin/php* -rwxr-xr-x 1 root other 40515124 Aug 6 10:49 /opt/php/5.2.3/bin/php* -rwxr-xr-x 1 root other 41271848 Nov 13 10:37 /opt/php/5.2.4/bin/php* We've been doing this with PHP/FastCGI for years now. Please advise. If there's anything else you'd like to see, please let me know and I'll be happy to add it in. How/where does PHP decide to launch in FastCGI mode v. CGI mode when it is exec'd by the web server? Did the win32 changes in 5.2.2 leak into UNIX somehow?