After migrating from Media Temple DV 3.5 to Media Temple DV 4.0, I found my email box filling up with notices of cron errors. Sometimes, the error was “-: wget: command not found” or other times “-: php: command not found”. Commands worked perfectly fine if run in SSH but not through the Plesk Cron Tab (Scheduled Tasks).
Initially, calls to the normally superb Media Temple Support resulted in several unsatisfactory replies such as “crons should work just fine on Plesk 10” or “we really don’t support crons”. I tried everything. Believe me, several weeks living without crons was not fun. Databases didn’t get backed up, emails didn’t go out, cleanup scripts didn’t run, etc. Then finally, a senior support engineer at Media Temple put me on the right track by mentioning that the user (i.e., the service) requires shell access to run crons in Plesk 10.
This is discussed, albeit somewhat cryptically, on Page 166 of the Plesk 10 Administrator Guide.
In previous versions of Plesk, the users who were granted the permission to schedule tasks with cron but were not allowed access to server shell, could still run scripts in the shell under which the cron was running. This allowed them to gain access to the data that could be potentially used to compromise the server. Starting from Parallels Plesk Panel 10.1, execution of cron tasks is automatically restricted to the chrooted shell environment.
If you trust your customers enough to allow execution of scripts in a non-chrooted environment, then you can select the required shell by issuing the following command in the console…
The Guide goes on to mention bin/sh. Therefore, I went back to Plesk 10 and changed the shell access for each domain running crons. See below.
Voilà! Crons started working immediately.
Tip: Use commands in starting with “php” rather than “/usr/bin/php”.
Examples:
php /var/www/vhosts/example.com/httpdocs/myfile.php >/dev/null 2>&1
wget -q http://example.com/myfile.php