I have a program that returns a comma-separated string of numbers after doing some background processing. I intended to run this in symfony using shell_exec; however, all I get is NULL (revealed through a var_dump(). I tried the following debugging steps.
I ran the file (it's a PHP class) through a command-line lime unit test in Symfony - it works and gives the correct result there.
Just to check, I tried a simple command ls -l at the same place to see whether I would get anything. Again, I had the same problem - the var_dump in the browser showed NULL, but it worked through the command line.
What could be the problem? Are there restrictions on running shell_exec() in a browser?
EDIT: Just to clarify, shell_exec() commands work when I run them as standalone php scripts on the web server (for example, by putting them in my document root. They don't seem to be working under the symfony framework, for some reason.
I finally solved it, and it turned out to be something quite simple, and quite unrelated.
The shell command I was running was in this format: face_query -D args. I didn't realize that Apache would be executing PHP as user www-data and thus the program face_query wouldn't be in the PATH (the directory is actually ~/bin). Changing the program name to the full path of the program solved it.
I also gather from this that only commands which www-data has permission to execute can be run. In this case, www-data is in the same group as my user, but it might be a problem otherwise.
Have you tried using exec? Or one of the other variants. I am never sure of which one to use and always lump with exec.
http://uk.php.net/manual/en/function.exec.php
Is your web server running php in safe mode?
Note: This function is disabled when PHP is running in safe mode.
From: http://php.net/manual/en/function.shell-exec.php
Related
Ok, after having bashed my head on this for hours I decided to ask for help. I have a Windows Server 2008 running Apache 2.4 and PHP 7.1. My application must run a PHP script on the server when the user clicks a button on the browser.
This is working fine on my desktop with Windows 10. However, on the server, exec() returns "null" and an exit code of 255.
I read all I could find on exec() issues and tried the following:
exec("C:\\PHP7\\php.exe -v", $output);
I got the proper response containing PHP's version information.
Then I decided to check the configuration files:
exec("C:\\PHP7\\php.exe --ini", $output);
All files were in place.
Then I decided to perform a syntax check on my script:
exec("C:\\PHP7\\php.exe -d display_errors=1 -l C:\\Apache24\\htdocs\\script.php", $output);
No errors were found.
Finally I decided to check the user account:
exec("whoami", $output);
Got "NT Authority\SYSTEM" as expected. To make sure that the script was able to run under the SYSTEM account I used SysInternals psexec:
psexec -s C:\PHP7\php.exe C:\Apache24\htdocs\script.php
Everything ran smoothly.
In other words, the script shows no problems when executed from the command line, either under a user account or the system account. I have also proven that PHP is being properly invoked by exec().
So, then I decided to check for "hidden" errors in my code adding the following two lines to the very beginning of the script:
error_reporting(E_ALL);
ini_set('display_errors', 1);
But, no joy. And I'm out of ideas.
Can any good soul help me on this?
Thanks a bunch,
Miguel.
Finally! The key to the answer was here: PHP exec() git fetch failing with return value 255.
I was unable to see any errors, even adding the "2>&1" pipe redirection to my commands. After reading that article, I learned that proc_open() is way better than exec(). Quoting from PHP's documentation:
proc_open() is similar to popen() but provides a much greater degree of control over the program execution
So, I replaced my exec() for a few lines of code (refer to the example in the manual) and found that the problem was being caused by the Zend Opcache, which was enabled for CLI. The quickier solution for me was to disable it in the command line:
php.exe -d opcache.enable_cli=0 myscript.php
VoilĂ ! Problem solved!
I am trying to do a simple project to start a VirtualBox VM using a PHP script. My server is win 7 ultimate and running php5.3 I am using the vboxmanage.exe to start the server. cmd works great in a batch file or typed right into cmd line.
When I use:
exec("path to vboxmange.exe" startvm "vm name");
it doesnt work. If I change the code to:
exec(dir);
it works fine. I did some searching and everyone seemed to mention permissions for IIS_IUSRS. I set it to have read and execute on the vboxmanage.exe and tried to do it for cmd.exe but cant seem to get it to allow me to do this, though it doesnt seem necessary as it can run other cmds like dir.
another theory I have is that exec wraps the entire cmd in "" and this doesnt work when I try to type it in to cmd line manually. I have tried to trim it off but that doesnt work cause exec adds it on so nothing I do before can stop this.
any suggestions for another way to do this or what it might be?
From exec in the PHP Manual:
Note: When safe mode is enabled, you can only execute files within the
safe_mode_exec_dir. For practical reasons, it is currently not allowed
to have .. components in the path to the executable.
Check the value of your safe_mode_exec_dir in your php.ini. I would guess that it would be fairly restrictive by default.
If that doesn't work, take a look in the comments. Particularly, this comment might be of help to you.
I am having an issue using the PHP function shell_exec().
I have an application which I can run from the linux command line perfectly fine. The application takes several hours to run, so I am trying to spawn a new instance using shell_exec() to manage better. However, when I run the exact same command (which works on the command line) through shell_exec(), it returns an empty string, and it doesn't look like any new processes were started. Plus it completes almost instantly. shell_exec() is suppose to wait until the command has finished correct?
I have also tried variations of exec() with the same outcome.
Does anyone have any idea what could be going on here?
There are no symbolic links or anything funky in the command: just the path to the application and a few command line parametes.
Some thing with you env
See output of env from cli (command line interface) and php script
Also see what your shell interpreter?
And does script and cli application runs from one user?
If so, se option safe_mode
Make sure the user apache is running on (probably www-data) has access to the files and that they are executable (ls -la). A simple chmod 777 [filename] would fix that.
By default PHP will timeout after 30 sec. You can disable the limit like this:
<?php
set_time_limit(0);
?>
Edit:
Also consider this: http://www.rabbitmq.com/
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.
I am using this php code:
exec("unrar e file.rar",$ret,$code);
and getting an error code of illegal command ie 127 ... but when I am using this command through ssh its working ... because unrar is installed on the server ... so can anyone guess why exec is not doing the right stuff?
Try using the direct path of the application (/usr/bin/unrar of whatever), it sounds like php can't find the application.
If you have chrooted apache and php, you will also want to put /bin/sh into the chrooted environment. Otherwise, the exec() or passthru() will not function properly, and will produce error code 127, file not found.
Since this comes up as a top answer in google, I wanted to share my fix:
The simple fix I had was to disable safe_mode in the php.ini file
; Safe Mode
; http://www.php.net/manual/en/ini.sect.safe-mode.php#ini.safe-mode
safe_mode = Off
thanx all for your response!!
I tried this
//somedir is inside the directory where php file is
chdir("somedir");
exec("/home/username/bin/unrar e /home/path/to/dir/file.rar");
and now it returned no exit code ... oher commands are doing file .. i tried mkdir etc .. :s
Just in case somebody else still gets this problem, take a look at the post here:
http://gallery.menalto.com/node/2639#comment-8638
Quote:
I found the problem. The problem was my security-paranoid OpenBSD. When upgrading from 3.1 to 3.2 they added:
Apache runs chroot'd by default. To disable this, see the new -u option.
The chroot prevented Apache from accessing anything outside of a directory, so I moved everything into the apache directory including netpbm. Everything was accessible and executable, but I guess it was still in some sort of "safe mode" because the exec() always returned 127.
Anyway, running httpd with the -u option went back to the less secure non chroot'd apache startup, which allowed the exec() to work again.
ohkiee guyz thanx ... and yes there might be some errors with $PATH ... but with given full path its working :)
exec("/home/user/bin/unrar e /home/user/xxx/yyy/file.rar");
I did not find the solution for my problem of the same type so sharing what was the cause of it in my Linux setup.
For whatever reason I needed an apache module loaded before other modules and so apache was started with LD_PRELOAD. As exec inherits the environment of the parent process LD_PRELOAD was used for starting the exec-ed program (through sh). Now the preloaded module uses some bindings to apache functions and of course they are not to be present in sh. The result of the php exec was an exit status of 127. The solution was to have in my php file a putenv("LD_PRELOAD") that gets executed before any exec calls.