Dmitry, you know it best. :)

Was your php compiled with --enable-fastcgi?

Try the following command:

$ sapi/cgi/php-cgi -i | grep "Server API"

Do you see CGI/FastCGI?

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.

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..:)

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.

What do you mean in "Using the php proc manager to control children"?
Could you show your configuration files.

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.

And you're sure php5 is the cgi binary and not the CLI binary?
As of some version we changed the binary name to be php-cgi. What was the configure line you used?

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?

And my point was that this happened (yes, it was needed to fix certain issues):

File: NEWS
-----8<------
31 May 2007, PHP 5.2.3
- Changed CGI install target to php-cgi and 'make install' to install CLI when CGI is selected. (Jani)
-----8<------

So what you have there called 'php' is actually the CLI binary. The cgi binary is called 'php-cgi'..

ARGH.  I misunderstood your comment.  In retrospect, I see what you were trying to say, and yes, that is indeed the problem.  I have closed the bug.  Thank you for the clarification.

I must apologize as it was my fault. I renamed it to be consistent with win32 builds + it makes sense to make difference between CLI / CGI this way and be able to always install both when they're build. Sorry about the trouble.. :I