Help me with this PHP exec() problem

Posted by mixersoft on June 22, 2007 at 8:23am

In my module I have the following lines of code to fetch a URL in the background using wget:

$script = "wget -b '$url' -a '/home/user/wget.log' -O -";

$path = "/usr/bin/";
if (file_exists($path."wget")) {
    drupal_set_message ("wget==".$path.$script);
    exec($path.$script);
    return true;
}

the exec() command never seems to run (hosted on linux) in the course of module execution, but if I cut and paste the output from the drupal_set_message() into my ssh shell, it runs perfectly.

Any ideas? is this is privilege issue? According to phpinfo(), safe mode is off.

Comments

Check under

Posted by gpk on June 22, 2007 at 8:30am

Check under disable_functions in the phpinfo output ...

gpk
----
www.gelst.com

gpk
----
www.alexoria.co.uk

What your web server's

Posted by themegarden.org on June 22, 2007 at 9:27am

What your web server's (error) log says?

How you have found that exec() didn't run?

---
Drupal Themes Live Preview - themegarden.org

----
Drupal Theme Garden

phpinfo disable functions

Posted by mixersoft on June 22, 2007 at 9:58am

phpinfo disable functions says "no value"

checked the apache2 error log and there is no entry for wget

I know the exec() hasn't run because the wget is logged in a mysql table, and it doesn't show up unless I do wget manually in the shell -- the very same command as what I am passing to exec().

I must admit that I'm

Posted by themegarden.org on June 22, 2007 at 11:33am

I must admit that I'm confused.

How wget is logged in a mysql table ?

Command from your code ( ... exec("/usr/bin/wget -b '$url' -a '/home/user/wget.log' -O -"); ...) doesn't write anything (as I know) to any mysql database.
It should write to file /home/user/wget.log

It is possible, that your web server doesn't have proper permissions to write to that file.
Try wget without '-b' option.
---
Drupal Themes Live Preview - themegarden.org

----
Drupal Theme Garden

Also I think that sometimes

Posted by gpk on June 27, 2007 at 4:29pm

Also I think that sometimes Apache's mod_security will disable URLs or commands that involve "wget". This is the case on our server anyway. You might be OK if you put your "script" in an actual script file on the server somewhere and exec'd that.

gpk
----
www.gelst.com

gpk
----
www.alexoria.co.uk

PHP Safe Mode might be active

Posted by traxer on June 23, 2007 at 10:12am

When PHP safe mode is active, only commands in the folder specified by PHP's safe_mode_exec_dir configuration option can be executed.

Edit: Next time I will read the whole of the post before replying. Promise!

--
~/.singatrue: file not found

Alternative to wget maybe?

Posted by dwees on June 24, 2007 at 11:19am

If the purpose of your wget is to save a large file from off the internet there is an alternative I had to use a few days ago (my internet connection was not great, and some downloads of some large files kept being interrupted, which meant that I could only get a partial download. Solution: Save the file to my shared web host account and download it at my convenience from there later).

Here is an example for multiple files.

<?php
ignore_user_abort(TRUE);
set_time_limit(600);

$filename = array();

$filename[] = "http://www3.telus.net/jefmil/2005/07/calibri.zip";
$filename[] = "http://www3.telus.net/jefmil/2005/07/cambria.zip";
$filename[] = "http://www3.telus.net/jefmil/2005/07/candara.zip";
$filename[] = "http://www3.telus.net/jefmil/2005/07/consolas.zip";
$filename[] = "http://www3.telus.net/jefmil/2005/07/constantia.zip";
$filename[] = "http://www3.telus.net/jefmil/2005/07/corbel.zip";

$replace = "http://www3.telus.net/jefmil/2005/07/";

for ($i = 0; $i < count($filename); $i++) {
  
  $rp = fopen($filename[$i], "rb");
  $wp = fopen(str_replace($replace, "", $filename[$i]), "w");

  if (!$rp) {
    die("Error opening file.");
  }

  while (!feof($rp)) {
    $content = fread($rp, 1024);
      fwrite($wp, $content);
  }

  fclose($rp);
  fclose($wp);

}
?>

My site: http://davidwees.com/myblog

system calls have return codes. Check them.

Posted by dman on June 29, 2007 at 12:09pm

Didn't you try actually capturing the response and checking its result?

<?php
$result = exec($command, $response, $return_code);
drupal_set_message(
  print_r(array('result was'=>$result, 'response was'=>$response, 'return code'=>$return_code ),1)
);
?>

Your webserver process probably may not run with the same privileges as your commandline user does.
If I want to see what my webserver sees, I go su www-data and run from there.

Here's a sample script, in which I attempt to get the webserver to install some needed fonts into its own path with its own permissions. It's likely to fail, so it's full of diagnostic output, telling me what the webserver process sees.

<?php
$dir = dirname(__FILE__);
$commands = array(
  "whoami",
  "fc-list",
  "ls -la ~/.fonts/",
  "ls -la $dir",
  "mkdir ~/.fonts",
  "cp $dir/*.ttf ~/.fonts/",
  "fc-cache -fv ~/.fonts/",
);

foreach($commands as $command){
  $response = "";
  print ("<h2>Running commandline <pre>$command</pre></h2>");
  $result = exec($command, $response, $return_code);
  print "<pre>";
  print_r (array('result' => $result, 'response' => $response, 'return_code' => $return_code) );
  print "</pre>";
}
?>

Try something like that for debugging commandline invocations.

.dan.
How to troubleshoot Drupal | http://www.coders.co.nz/

_{.dan. is the New Zealand Drupal Developer working on Government Web Standards}