During install, drush.php hosting setup tries to install a cronjob to process the queue, but on exotic flavors of Unix (exotically configured) sometimes the cronjob does not work. It could probably be make more portable.

Different flavors of Unix installs different implementations of cron(8) (Vixie, Dillon), different shells (bash, sh, csh, tcsh), and basically tend to present different environments to an entry in the crontab(5).
Sometimes the default 'just works', sometimes you have to install the explicit path to the php cli executable, sometimes you add a PATH=<something> statement at the top of the crontab(5), sometimes you wrap everything in a shell script and in the crontab(5) you just put a call to it. These are all solutions when the default doesn't work, and can be manually tried on the command line, after all...
Now, I know FreeBSD enough to fix the thing if it doesn't work, but I don't know enough edge cases to suggest the 'most portable' crontab(5) entry.
For instance, this is what worked for me (after a lot of random typing):

*/1 * * * * cd /srv/apache/aegir/htdocs; ./sites/all/modules/drush/drush.php hosting dispatch >/dev/null 2>&1

Note: I filed this issue because I share with Vertice the feeling that this must be filed somewhere, but (as Vertice does) I think that We don't really need this feature right now! So I am marking it postponed at birth.

Comments

mauror’s picture

Upon further investigation I have come to the conclusion that adding

PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin

at the top would probably make the crontab more portable.
In other words, it is what we *BSD people need and won't hurt the others :)

adrian’s picture

Status: Postponed » Fixed

fixed this in HEAD

ununtu people were being nailed by this and drush 2.1

the hosting setup command now replaces the crontab entry and specifies PATH and SHELL variables.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.