Call PHP from PHP: system("php ...") ?

puzzledone

Hello experts,

Trying to figure out why the very simple script below doesn't do what I think it should. A week of intense googling and experimenting didn't help. Any hints are appreciated.

I have test.php:

<?php
 print "foo\n";
 print system("php -v");
?>

When called from command line, the script behaves as expected:
- prints "foo"
- calls system()
- system() calls "php -v"
- "php -v" prints the PHP version
- last line of the version output returned by the system() and printed again

> php -q test.php
foo
PHP 4.4.9 (cgi) (built: Aug 12 2008 13:28:34)
Copyright (c) 1997-2008 The PHP Group
Zend Engine v1.3.0, Copyright (c) 1998-2004 Zend Technologies
Zend Engine v1.3.0, Copyright (c) 1998-2004 Zend Technologies>

However, when I call the same script via GET request, it goes into some weird recursion. It prints the "foo", then prints 2 HTTP headers, then "foo" again, and so on until the web-server kills it.

What I tried so far:
- using php5 and php6 in the system() call
- redirecting STDIN and STDERR of the "php -v" to a file - I see the recursion there as well, and right before it dies, there are some errors about not being able to fork (?)
- using exec() instead of system() - slightly different output but the same unexpected recursion
- using shell_exec()/backticks - also getting recursion
- replacing "php -v" with "echo bar" - it works
- replacing "php -v" with "perl -v" - also works

So, it looks like the issue only happens with calling PHP CLI from within PHP CGI (?). Looks like instead of just spawning /usr/local/bin/php as a separate process with it's own command line input, it somehow jumps to the top of the parent script. Note, the server this was tested on is not using safe mode.

The end goal is not to get the PHP version of course, it is to execute an external PHP script. Unfortunately, I am not able to use any other method to execute it (include, load as a file and then eval(), etc.). Must be the system() call. So, please don't suggest alternative solutions, I do know them, but must find a way to use system() for this.

Thanks !

dagon

why are you using a dangerously old php version 4.4.9?

what web server are you using?

have you tried the full path to php?

puzzledone

why are you using a dangerously old php version 4.4.9?

We'd have to ask 1and1 that.

Does the version matter though ?

I just tried renaming the test.php to test.php5 (so that it uses v5.2.14) - same behavior.

What I realized though is that the recursion happens in the CLI part. If I keep the script itself as v4 (.php) but call v5 in system() ("php5 -v"), this is what I get:

foo X-Powered-By: PHP/5.2.14 Content-type: text/html
foo X-Powered-By: PHP/5.2.14 Content-type: text/html
...
Warning: system() [function.system]: Unable to fork [php5 -v] in /homepages/.../test.php on line 3

what web server are you using?

Apache. Can't tell you which version - they don't send it in the headers.

have you tried the full path to php?

Just tried that, same result.

bradgrafelman

Just out of curiosity, does the same thing happen if you replace [man]system/man with [man]shell_exec/man ?

puzzledone

See original post - tried that already.

dagon

i would ask the host at some stage there are a lot of ways to configure php.

puzzledone

Well, 1and1 is a large hosting firm, their configuration is probably pretty standard/average. But no matter how you configure php, do you agree that this code should not behave the way it is ?

dagon

puzzledone;10971344 wrote:
Well, 1and1 is a large hosting firm, their configuration is probably pretty standard/average. But no matter how you configure php,

I've hosted at a dozen places, i don't know what standard is as they all differed.

puzzledone;10971344 wrote:
do you agree that this code should not behave the way it is ?

yes.

puzzledone

Is there a way to enable debug/verbose output in either PHP CGI or PHP CLI, by end user ?

Basically, by the looks of it, instead "php -v", the PHP CLI ens up being executed with "-f test.php" as a parameter, and ends up in the (endless) recursion.

dagon

i know this is not an ideal answer but in the past i have moved a client from one host to another due to the hosts php setup (disabled functions, in one case)

puzzledone

Unfortunately this has to work on a random/average host (yes, I know we concluded there is no such thing 🙂).

Or, alternatively, I have to have solid understanding why it doesn't work (and may be even submit a bug report to hosting or php developers).

Any other ideas, allmighty all ?

dagon

lots of hosts disable exec (et al), is this the only way to do it? and what is it anyway?

puzzledone

See the original post - system("echo bar") and system("perl -v") works. So, exec-like functionality is not disabled.

Without going into details, this is an attempt to automate some system maintenance. There is a bunch of servers that have a web-based, PHP-based management system that, among other things, allows admins to execute shell commands (by passing commands to PHP's system() - no comments about security of that please).
Now, there are also other PHP-based maintenance scripts on these servers. However, they are not part of the larger management system, and are not covered by the same authentication and session management framework. For that and other reasons, they are not made accessible to direct HTTP GET requests.
These are the scripts we need to run. And the only way to call these scripts is by going into the management system and launching them via "php -f other_script.php" that gets passed to system() call.
For a bunch of other reasons we don't allow SSH to these boxes either, so, can't just do that from SSH CLI.

Believe me, a bunch of good sysadmins are looking at this mess now and until we develop a better long-term solution, this is the best/fastest option to automate some very time consuming tasks. The next easiest/fastest option would be to rewrite these .phps in Perl (as system("perl xxx") seems to work). Or other exotic solutions like using system() to schedule a cron job to run these .phps. But that opens more cans of worms than it closes :.

So, back to PHP (so that I'm not kicked out for off-topic): what to do with <?php system("php -v"); ?> not working ? Anyone able to test it on their host ? So far I know it doesn't work on our internal servers and on (some) 1and1 servers.

dagon

puzzledone;10971493 wrote:
See the original post - system("echo bar") and system("perl -v") works. So, exec-like functionality is not disabled.

i was referring to: "Unfortunately this has to work on a random/average host "

all seems odd to me to be on a shared host, i would not put anything but the simplest unimportant web sites on such a platform, you should have a dedicated server for anything of 'impotance'

bradgrafelman

puzzledone;10971493 wrote:
So, back to PHP (so that I'm not kicked out for off-topic): what to do with <?php system("php -v"); ?> not working ? Anyone able to test it on their host ? So far I know it doesn't work on our internal servers and on (some) 1and1 servers.

Output on my home computer is:

PHP 5.3.4 (cli) (built: Dec  9 2010 21:37:21) 
Copyright (c) 1997-2010 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies

using Apache 2.2.17 on Windows 7.

On my shared *nix server, I get:

PHP 4.4.8 (cli) (built: Jan 18 2008 08:08:39)
Copyright (c) 1997-2008 The PHP Group
Zend Engine v1.3.0, Copyright (c) 1998-2004 Zend Technologies

and:

PHP 5.2.14 with Suhosin-Patch 0.9.7 (cli) (built: Sep 20 2010 18:26:04) 
Copyright (c) 1997-2009 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2010 Zend Technologies

(the latter being the result of changing "php" to "php5" in the shell command), both with no apparent errors/problems.

dagon

yup works on all the work servers i could be bothered testing and on the windows localhost.

puzzledone

Hm. I guess I'll have to get a few of php.ini's from these boxes and see if I can spot anything that breaks it. Not that it will be easy to have it changed though.
What puzzles me is that this is broken not just on our internal servers (I can understand if they were tweaked at some point in time - they don't host too many different applications), but on an "average" shared host as well (1and1 in my example) - where I would expect configs to be as generic as it gets. I guess 1and1 is not average after all.

puzzledone

Wait a second, I just noticed something.

In my test done from SSH CLI, the output was:

> php -q test.php
foo
PHP 4.4.9 ([B]cgi[/B]) (built: Aug 12 2008 13:28:34)
Copyright (c) 1997-2008 The PHP Group
Zend Engine v1.3.0, Copyright (c) 1998-2004 Zend Technologies
Zend Engine v1.3.0, Copyright (c) 1998-2004 Zend Technologies>

Note the item in bold. WTF does my CLI command end up launching the "cgi" version of PHP ?

In bradgrafelman's 3 tests, where the CGI script launches CLI command the output was correct:

PHP 5.3.4 ([B]cli[/B]) (built: Dec  9 2010 21:37:21) 
Copyright (c) 1997-2010 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies

PHP 4.4.8 ([B]cli[/B]) (built: Jan 18 2008 08:08:39)
Copyright (c) 1997-2008 The PHP Group
Zend Engine v1.3.0, Copyright (c) 1998-2004 Zend Technologies

and

PHP 5.2.14 with Suhosin-Patch 0.9.7 ([B]cli[/B]) (built: Sep 20 2010 18:26:04) 
Copyright (c) 1997-2009 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2010 Zend Technologies

It appears that I am not able to launch PHP CLI even from CLI; I'm getting the CGI version. I am not familiar enough with PHP installations - is it possible that PHP CLI is just not installed, and how do I verify that ?

bradgrafelman

Try doing a which php to find out where the php binary is, and do a ls -l /usr/bin/php* (replacing "/usr/bin/" with the path you discovered via which) and post the output of the 'ls' command here.

EDIT: For example, in my Ubuntu VM, I see this:

-rwxr-xr-x 1 root root 12596720 2010-12-25 04:09 php
-rwxr-xr-x 1 root root 12613328 2010-12-25 04:09 php-cgi
-rwxr-xr-x 1 root root     2414 2010-12-25 04:09 php-config
-rwxr-xr-x 1 root root     4490 2010-12-25 04:09 phpize

which shows that there is a separate binary to run the CGI version of PHP (and that the two are not simply the same - note the file sizes).

dagon

Ha, well try using Lynx, Wget, Get or cURL then

print system("wget -q -O - 'http://www.domain.com/file.php' >/dev/null");