I have a PHP script that needs to run from command line. One of the function it calls is socket_create.
In php.ini, I have included the following in order to get that function working (see the comment on http://www.php.net/manual/en/sockets.installation.php):
extension=php_sockets.dll
How do I run the script from command line such that it doesn't complain that socket_create is an unknown function? Does PHP CLI actually respect what's in php.ini? I thought it was supposed to, but I do get errors when running it via CLI and no errors when running it via the browser.
UPDATE: by the way, I'm testing this out: https://github.com/nicokaiser/php-websocket. I assume that the server needs to be executed via command line.
A different php.ini file may apply when running php on the CLI rather than as a web server module. You appear to be using Windows, so I'm not sure where this file may be, but it could provide a clue; look for several php.ini files in your disk and see if one of them applies to CLI invocations.
Related
I have added this line PATH DEFAULT=${PATH}:~/bin/ to the ~/.pam_environment
This allows me to call ffmpeg from command line without path which is obviously in ~/bin/ dir so everything works fine as long as im ussing command line.
But if try to run the exact same command from php all i get is sh: ffmpeg: not found
And the code is
shell_exec("ffmpeg 2>&1");
So from my very little experiance with linux (in this case Ubuntu to be specific) i guess apache has no access to pam_environment or ~/bin
What can i do to make this work?
look at the output of phpinfo(), it has a section with all environment variables it sees. then look at your webserver configuration, maybe it's sanitizing the environment, or maybe the init script which starts your webserver does it.
and is the account the webserver is running under using PAM at all?
I've a PHP script that uses cURL to perform certain tasks. At the moment, I have the script running every 10 minutes. This is what I'm running via Windows Task Scheduler.
C:\wamp\bin\php\php5.4.3\php.exe -f C:\wamp\www\autoscripts\index.php
However, for some reason, whenever the argument quoted above is run through the command line, I get the error "Fatal error: Call to undefined function curl_init()". The script works perfectly when I access it via the browser. Is there any reason why PHP isn't able to access the cURL extension via the command line?
Most likely running from command line does not use any ini file that loads the extensions. Open phpinfo() from the browser, copy path to loaded ini file and change your task to:
C:\wamp\bin\php\php5.4.3\php.exe -c "C:\path\to\php.ini" -f C:\wamp\www\autoscripts\index.php
Figured it out. Basically, on WampServer, there are TWO php.ini files that you need to be aware of.
C:\wamp\bin\php\php5.4.3\php.ini
C:\wamp\bin\apache\apache2.2.22\bin\php.ini
Forgot that the command line uses a different ini file than the web server. :(
Like many others I have problem with shell_exec() function in PHP. I have safe mode disabled and disabled_functions deleted from php.ini.
If I run php script from terminal (php print.php) it's working perfectly but if I run it from web browser nothing happens.
Here is the scipt:
<?php
$output = shell_exec('lp print.php');
echo "<pre>$output</pre>";
?>
Please help me. I'm running PHP 5.3.10 on Apache2. My OS is Ubuntu Server 12.4. Here is the phpinfo page: http://testni-server.info/info.php
Progamming language PHP allows one to limit executing of external commands via configuration directive safe_mode_exec_dir. This directive should contain full path to a directory conatining programs which PHP script can run. If the script tries to execute a command not located in this directory, the command is not executed. This configuration directive is active only if safe mode is enabled, which means more and sometimes unwanted restrictions to users. PHP has no known possibility to limit executing of external commands with disabled safe mode. Teherefore, here is a patch adding special directive exec_dir straightly into PHP. This directive is very similar to safe_mode_exec_dir, but safe mode has not to be enabled.
This patch limits or corrects the behavior of these functions:
exec()
passthru()
proc_open()
shell_exec()
system()
popen()
is_executable()
The patch was created for purposes of limit execution of external commands of users on a multidomain apache server, first for PHP version 4.2.1. The patch was sent to PHP developers so it could be a part of PHP, but no one of PHP developers was interested in. On the other side, some PHP users wanted this patch, therefore this site was created.
Your command line (CLI) PHP might be using a different working directory and/or path than the CGI one. Try defining the working directory (containing the lp command) explicitly with chdir() before calling shell_exec().
it's a bit complicated. :-) I have a website written in PHP that needs to call an external program written in .NET, running under Mono. It calls the program with:
/path/mono /path/executable arguments...
as per usual (I also tried to put this into a bash script and call the script itself from PHP).
As far as I can tell, everything is set up as required. Mono itself running all right, executable (or script) with executable rights, owners are all right. The correct setup can also be ascertained from the fact that if I issue the command line above (or call the script mentioned) from a command line on the server (Debian Lenny), everything works perfectly, my executable is executed without error.
But, if PHP calls the same (using exec(), system() or any other variant), I immediately get an exit code of 6 from Mono and my executable is not run at all (in order to test it, I use a "Hello World" executable that does nothing but emits a single output line and returns 0). Compiled without any additional dependency, just a real "Hello Word". It's absolutely sure that this program doesn't return the exit code 6, it must come from Mono but I couldn't find it documented anywhere.
I can call anything else from PHP, so it's not safe mode or any similar restriction that would keep me from executing external programs from PHP.
Thanks for any idea...
Try to execute mono from the command line but with the user running the webserver (www-data or apache).
ej.
#su apache
$/path/to/mono /path/to/program.exe
The common problems that I have using exec is a different environment variables (look if is bash or sh what apache is using), permissions to the user/group of apache, etc.
When I call /usr/local/bin/pdftk from PHP in Apache (via shell_exec(), exec(), system(), etc.), it returns the SYNOPSIS message as expected.
When I call /usr/local/bin/pdftk input.pdf fill_form input.fdf output output.pdf flatten via shell_exec(), nothing returns.
When I copy and paste the exact same string to the same path in the shell (as the apache user), the output.pdf file is generated as expected.
Moving the pdftk command into a PHP shell script (shebang is #!/usr/bin/php) and executing it with php script.php works perfectly.
Calling that shell script (with its stderr redirected to stdout) from PHP in Apache (via shell_exec(script.php);) results in this line:
sh: line 1: 32547 Segmentation fault /usr/local/bin/pdftk input.pdf fill_form input.fdf output output.pdf flatten 2>&1
Whenever I run the script from the command line (via PHP or directly), it works fine. Whenever I run the script through PHP via Apache, it either fails without any notification or gives the SegFault listed above.
It's PHP 4.3.9 on RHEL4. Please don't shoot me. I've set memory to 512M with ini_set() and made sure that the apache user had read/write to all paths (with fopen()) and by logging in as apache ...
Just went and checked /var/log/messages to find this:
Oct 4 21:17:58 discovery kernel: audit(1286241478.692:1764638):
avc: denied { read } for pid=32627 comm="pdftk" name="zero"
dev=tmpfs ino=2161 scontext=root:system_r:httpd_sys_script_t
tcontext=system_u:object_r:zero_device_t tclass=chr_file
NOTE: Disabling SELinux "fixed" the problem. Has this moved into a ServerFault question? Can anybody give me the 30 second SELinux access controls primer here?
php-cli & php-cgi (or the module, depends on what your server uses) are different binaries. They don't even have to share the same version to live happily side by side on your server. They also may not share the same configuration. Increasing memory usually does nothing to help Segfaults. Points to check:
Are they the same version?
Do they have the same settings (consult the *.ini locations loaded in the phpinfo(); output, and possibly the whole output itself), if not: try what happens if you alter the one for your webserver to the one for the cli as far as possible.
Segfaults occur more in extensions then in the core afaik, and sometimes seemingly unrelated. Try to disable unneeded extensions one by one to see if the problem goes away.
Still no success? You may want to run apache with gdb, but I have no experience with that, it might tell you something though.
No luck? Recompile either the module of cgi your webserver uses.
It's PHP 4.3.9 on RHEL4. Please don't shoot me.
I feel more sad for you then anger, we're beyond the 5.3 mark, come over, it's a lot more happy here.