[suPHP] SuPHP recursive forking

[John Lightsey]

On Sep 24, 2008, at 4:13 PM, J.D. Tysko wrote:

> Hi,
>
> We have a PHP application which needs to exec off another PHP process.
> The problem is, is that when we use a command with "php" in it,
> recursive forking is started.
>
> We installed this software on a server running CPanel running SuPHP.
> when we tested the software we had a catastrophic failure where
> thousands of processes were being spawned off.  Through an extensive
> debugging process, we were able narrow the issue down to SuPHP.  I  
> have
> attached a test script displaying this behavior.  When the script is  
> run
> from the command line, It functions correctly.  When it is run as a  
> CGI
> script on the web, it fails 2 ways: If you click the "Go POST" button,
> the script runs, but the output in the log file is incorrect, being a
> complete http response rather than the php version info. If the "Go  
> GET"
> button is clicked, the script will execute once in the browser, then
> continue forking itself, outputting the same thing as the post method.
> Our guess is that SuPHP revisits the GET command which causes a
> recursive loop.  Can you please advise us how we can get this working?

This problem is somewhat cPanel specific because of the configuration  
of mod_suphp and the way PHP is installed on cPanel systems.

On a cPanel machine /usr/bin/php is the PHP CGI binary and /usr/local/ 
bin/php is the PHP CLI binary.  In /opt/suphp/etc/suphp.conf the  
env_path is set to /bin:/usr/bin.

So...  If you're running a PHP script via mod_suphp on a cPanel system  
and you just exec('php -v'), it's going to find the PHP CGI binary  
instead of the PHP CLI binary.  As others have mentioned, the PHP CGI  
binary doesn't care about the arguments you supply if it see  
SCRIPT_FILENAME set in the environment.  This goes beyond mod_suphp as  
well.  BSD systems have a reversed path with /usr/bin/ searched  
before /usr/local/bin/, so even using libphp you might run into the  
same issue on some systems.

The best fix is to always supply the full path to the PHP CLI  
interpreter.

You can also clean up the environment by deleting DOCUMENT_ROOT,  
SERVER_SOFTWARE, SCRIPT_FILENAME and probably a few others.  Even with  
those deleted the PHP CGI binary behaves differently than the CLI  
binary.  I've seen quite a few systems where the CGI binary will  
generate fatal memory errors after the PHP script has been fully  
executed.  Better to use the CLI binary if possible.

You can also explicitly set the PATH environmental variable in your  
script.

You could also set env_path in suphp.conf to match the standard system  
PATH /usr/local/bin:/bin:/usr/bin

J.D.