I have configured a user crontab file as follows:

*/2 * * * * /Users/[my user]/Dropbox/htdocs/auto-update.sh

But it won't execute. I waited for, like, 10-15 minutes. Why?

Command auto-update.sh runs easily if executed manually. How can I break apart the chain of execution and get my script running from cron?

  • 1
    What OS are you running? Cron is deprecated on OS X so you might need to start the daemon? – bmike Jan 9 '14 at 16:11
  • Latest, 10.9.2. How do I do it? I just want a script to work every hour, for instance. In above script I was desperate because it didn't work, and modified it to work every 2 mins. – RomaValcer Jan 9 '14 at 16:55
  • 1
    The cron daemon should be automatically started (by its replacement, launchd) if a crontab file exists. See /System/Library/LaunchDaemons/com.vix.cron.plist (especially the KeepAlive and QueueDirectories items). – Gordon Davisson Jan 9 '14 at 23:14
  • OK, Keeplive is there, but only path listed there is '/etc/crontab' that doesn't exist. In QueueDirectories there is existing file in restricted folder '/usr/lib/cron/tabs'. When opening it with su and vim, there is my task. – RomaValcer Jan 10 '14 at 3:35

The environment a cron job runs in is quite a bit different from an interactive shell; it's likely that the script is running, but not successfully. One of the biggest differences are that for cron jobs, the default PATH is just "/usr/bin:/bin", so if you use any commands that aren't in /usr/bin or /bin, they won't be found unless your script either sets its own PATH, or supplies explicit paths to commands. The other big difference is simply that it's not connected to an interactive session, so if it tries to do anything interactive (read from the terminal, etc) that'll fail. Try changing the cron entry to:

*/2 * * * * /Users/[my user]/Dropbox/htdocs/auto-update.sh >>/tmp/auto-update.log 2>&1

...and see if anything informative shows up in the log.

  • This is better than my effort - feel free to incorporate my logger idea if it makes your answer any better. – bmike Jan 9 '14 at 23:14
  • Log just didn't appear. – RomaValcer Jan 10 '14 at 3:42
  • @RomaValcer: that's strange -- it means it isn't even getting as far as launching the script. I'd run ps -ax | grep [c]ron and see if it lists the cron daemon (/usr/sbin/cron) running. If it is, try bmike's logger test. In any case, check the logs (/var/log/system.log and the "All Messages" item in the Console utility) and see if there's anything relevant-looking. – Gordon Davisson Jan 10 '14 at 6:32
  • Yeah, it is there. But logs don't show anything that starts on scheduled time. – RomaValcer Jan 10 '14 at 11:48

It's tough to tell, but what if you added a second cron job to execute every 5 minutes or so and have it call some system built tool that logs messages to system.log?

0,5,10,15,20 * * * * /usr/bin/logger "cron is working"

That way you'll know that cron is running for the user in question and can focus on either starting cron or fixing your script so it runs in the limited cron environment. (You can look at the wall clock and pick a few times that are coming up soon or even the next few minutes - e.g. editing at 12:34 put in 35,36,37,38 for the minutes to run and save the cron file.)


It's been a while that you asked this question, but it seems that no solution came up in this thread.

Depending on the way you create a user-crontab, it might be necessary to execute this after editing it:

crontab ~/.yourcrontabfile

To see if the new crontab (also after modifying it) has been activated, check with:

crontab -l
  • That doesn't work. Crontab -l shows crons are set up, but it still doesn't work. – PKHunter Mar 31 '17 at 11:43

I had the same problem. You need to add the path to your bash script:


I had the same problem. It went away after I added a newline after my job in my crontab file (I'm a total crontab n00b, so I have no idea if this behavior is widely known or not).

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .