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.
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 have a problem trying to run passthru function in my php code (Joomla module). the code is following (this is only a snippet)
ob_start();
passthru("/usr/bin/whois 85.70.231.130 | /usr/bin/grep 'address:'",$code);
$whoisData = ob_get_contents();
ob_end_clean();
$whoisData = str_replace("address:", "", $whoisData);
$whoisArray = split("\n",$whoisData);
echo trim($whoisArray[1]);
when I run this on my localhost, it echoes what it should, but when I run this code on the production server, it echoes nothing and the $code variable contains 127 (command not found). I tryied add absolute paths to these commands into the passthru function, but it didn't helped. Interesting is, that when I run the code right from terminal via ssh and php command, it runs well, but when it's called from application context it doesn't. Does anybody know what I should to do?thanks
SOME EDITS..
safe_mode is on
webserver does not see into /usr/bin and /bin/ folders so what is the best way how to run these commands from php?
usr/bin/grep doesn't look like a valid path to a command.
The missing / at the beginning of the path to the second command might explain the command not found error... even if the first whois command is found.
Have you looked to see if your webserver / php is running chrooted?
print_r(glob('/*'));
if (file_exists('/usr/bin/grep') && file_exists('/usr/bin/whois')) {
print "maybe its a permissions thing?\n";
} else {
print "can't see executables required\n";
}
should give you a clue.
So I have already solved my problem with phpwhois library. I seems like with my server configuration is it unlikely that these functions will be working well. So thanks for your help:)
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.
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