0
votes

Some setup background first:

  • I have a cronjob which runs a PHP file called worker_cronjob. All the file does is download my worker from git and the cronjob in cron.d looks like:

    */1 * * * * ubuntu /home/ubuntu/worker_cronjob >> /home/ubuntu/worker.log

  • It includes the worker_despatcher file

  • Which fires off a child process with (ROOT being an abolsute path to my directory):

    $PID = exec(sprintf("%s > %s 2>&1 & echo $!", "php ".ROOT."/worker/encoder.php".$arg_string, ROOT."/worker/encoder.log"));

The problem is that under a cronjob this method is changing the way system commands are run, more specifically sh. So when I run a command like:

ffmpeg

It returns:

sh: 1: ffmpeg: command not found

After trail and error I have discovered this only happens from the cronjob, somehow it is changing the way directories are set, much like chrooting without me calling chroot.

I have looked at other threads and it says it use full paths when creating cronjobs and running files, however it's not my files that's the problem and they are all referenced via absolute paths, it is running installed programs where I get problems.

Does the absolute path apply to installed apps as well or is there a way to break this functionality to give me back the ability to just run a command with one word?

1
use also absolute path to the ffmpeg command and see what happens - Itay Moav -Malimovka
Create a bash script that's called in the cronjob line. So you can more easily configure how ffmpeg is invoked and you can simúlate what happens when it is called by root or some other user in some other shell with a different environment and all that stuff. - hakre
Indeed, seems I'll have to do something like that since using absolute paths all over my PHP script to invoke it is just nasty. But yea using absolute paths worked, personally very weird behaviour in my opinion, thanks for the help :) - Sammaye

1 Answers

1
votes

The behind reason is that cronjobs are run by the system, so they know nothing about your shell or user environment variables. You can say they run in a minimal environment.

A great detailed answer can be found in Reasons why crontab does not work.

Another way not shown in the above link resource is:

* * * * * PATH=/usr/bin; command >> /var/log/command.log