I ended up finally solving this, but wanted to document it for others.

Drush runs fine from the command line, in a shell script triggered manually, but doesn't run from cron. And yeah, you've already done the basics like filling in the full path to the file. MADNESS!

Here's a great blog post I stumbled across looking for something only tangentially related: http://blog.spikesource.com/crontab.htm.

The trick is that even though crontab is running as your user, it doesn't use your user's environment variables like PATH, SHELL, etc. It does this solely to piss you off and make you waste lots of time.

So to figure out what the difference is, do this handy trick:

$ env > /tmp/myenv.log
$crontab -e
* * * * * env > /tmp/crontabenv.log

Then diff the two, and start copy/pasting. In my case, I needed to copy over PATH to the top of crontab -e.

Hope this saves someone else some hair.


Status: Fixed » Closed (fixed)

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

moshe weitzman’s picture

Just the tip I needed today. Thx.

domidc’s picture

Component: Code » PM (dl, en, up ...)

The blog post was removed. Can you still post the tip?

domidc’s picture

Excuse me, read to quickly. The tip was already there. Thanks!

therainmakor’s picture

I thought I would share what I have found to be the easiest way to accomplish this (after much trial and error).

In your cron script, ssh back into your box and run the script that has the drush commands in them in the form of the command below. Your ssh login will get all the correct environment settings as if you were normally ssh-ing into your server. This also allows the correct use of drush site aliases (i.e., @site.live, @site.stage, etc.).

# Cron command to run
ssh user@host script_to_run_that_has_drush_commands

You will need to make sure you have you have an ssh private key setup from your server back into your sever.

I hope this helps.

ressa’s picture

Thank you @therainmakor! I tried to make crontab execute a bash script for three hours last night in vain, when I should just have gone to the Drush issues and searched for crontab :-)

I tried many things: writing absolute paths, checking that the .sh script was executable and permissions were right, rewriting the variables with brackets, like this: ${TMP}, changing the date format from `date +%Y-%m-%d` to $(date "+%Y-%m-%d"), including some extra paths in the crontab file, with bash in front of the script and without, etc., but it didn't work no matter what I did. So when I found your post I, and it worked right away I almost couldn't believe it, so thank you very much for sharing your solution.

selfuntitled’s picture

Version: » 7.x-5.8

Hey - I know this is a stale thread, but I was having this issue and found a better solution than remoting into your box with ssh.

Assuming you've installed drush using pear as is currently recommended here
Drush should be in one of your bin folders, probably /usr/local/bin which is very likely already included in your path when you're in a shell session.

Odds are pretty good cron is running with much less in it's path, and that's why it can't find the command.

The solution I've found that works most consistently is to update the path variable in your shell script itself before you do anything.
So the steps are the following:
Log in to ssh as the user that will be running the cron job.
1. Run which drush which will tell you where Drush is running from - probably /usr/local/bin/drush
2. At the beginning of your shell script, update the $PATH variable with with the directory where Drush is installed, in my case:
export PATH=$PATH:/usr/local/bin

johnlaine’s picture

This worked perfectly for me, thanks so much for taking the time to post it.

roblog’s picture

Issue summary: View changes

Massively helpful! Thanks

lukasss’s picture

#7 worked perfectly for me