10

I have recently switched from Ubuntu to MacOS. I tried to run the exact same cronjobs I ran on Ubuntu before, however they don't, and after trying to figure out if the crontab entries might have any errors, I more and more had the suspicion that cronjobs don't run on my MBP at all, so I added this line to crontab -e:

*/15 * * * * touch /Users/<my-user>/cronjob-success-"$(date +%Y%m%d)".txt

I'd expect it to run every 15 min (xxh15, xxh30, ...), however no new files appear. I also don't see any logs indicating cronjob runs.

The file exists in /usr/lib/cron/tabs/<my-user>. What am I doing wrong that this doesn't work?

I am on Catalina 10.15.6

Improve this question
7
  • 2
    You will need to grant permissions for command line tools to run on Catalina.
    – bmike ♦
    Commented Sep 26, 2020 at 22:10
  • I apologize. My comment was entered as an answer and come code has decided it’s a comment and not an answer. See apple.meta.stackexchange.com/questions/3969 for details.
    – bmike ♦
    Commented Sep 26, 2020 at 22:13
  • Also, did you add terminal app to the full disk entitlements and log out / restart?
    – bmike ♦
    Commented Sep 26, 2020 at 22:27
  • Wasn't cron depreciated for launchd a few years back?
    – Steve Chambers
    Commented Sep 26, 2020 at 22:50
  • 5
    cron treats % characters in the command as line delimiters; you need to escape them like ...date +\%Y\%m\%d... for the command to work.
    – Gordon Davisson
    Commented Sep 27, 2020 at 0:01

2 Answers 2

Reset to default
9

I'd recommend a couple of things:

  1. Make sure cron has Full Disk Access in the Privacy tab of System Preferences (see s/s below) enter image description here
  1. When creating commands in crontab, help yourself out by writing errors generated by stderr to an output file using 2>&1, and using full pathnames (your cron job does not run w/ same environment as your user does);

EXAMPLE:

seamus@Dung-Pro ~ % crontab -l 

*/5 * * * * /usr/bin/touch /Users/seamus/scripts/cronjob-success-"$(date)".txt

SOME OTHER IDEAS:

  1. crontab guru: https://crontab.guru/

  2. not always necessary, but using full path to command is a good habit!

  3. it often helps to re-direct stderr (aka 2) to a file for review when things go wrong

  4. re-direct may be done as follows:
    >> /home/pi/cronjoblog 2>&1

    This redirects stdout to /home/pi/cronjoblog and redirects stderr to stdout; i.e. both streams will be written to the file.

  5. Finally, wrt the specific command in your question: that does not run for me either - it has something to do with the formatting specified for the date command - date with no formatting works fine. If you need to use that specific format, you should try @GordonDavisson comment to your question.

Improve this answer
5
  • 3
    Hey! Thanks for this. Others were partly right, but your answer is the most complete. In fact I had (and partly still have) a series of issues. Firstly, indeed I had to give Full Disk Access to cron. Secondly, it my test cronjob was indeed faulty and did not work. Your example did! I also logged stderr now and got /bin/sh: flock: command not found. I use flock to not run the same rsync twice. I am aware that it's original a linux thing, but I have installed github.com/discoteq/flock and the rsync works with flock from my user. I suspect cron uses another user and that breaks it?
    – Yanick Nedderhoff
    Commented Sep 27, 2020 at 16:48
  • If I type which flock I get /usr/local/bin/flock. I am not sure what to do with this though.
    – Yanick Nedderhoff
    Commented Sep 27, 2020 at 16:49
  • So, turns out I ignored one part of your answer. I had to specify the full path as you said (/usr/local/bin/flock) and it worked :) Thank you!
    – Yanick Nedderhoff
    Commented Sep 27, 2020 at 17:31
  • 1
    @YanickNedderhoff: Glad that helped. cron is an invaluable tool, IMHO. The key to getting results is (as in most things), is understanding its limitations. And thanks for the feedback - I should have made that business with the full path specification more prominent.
    – Seamus
    Commented Sep 27, 2020 at 17:57
  • 2
    I wish I could give you both more than one upvote. Super helpful explanations how to get to the right set of fixes.
    – bmike ♦
    Commented Sep 27, 2020 at 18:33
2
Improve this answer
6
  • I did read about this before, but it does not seem to fix the issue in my case. I did at /usr/sbin/cron to Full Disk Access, but still the jobs don't run.
    – Yanick Nedderhoff
    Commented Sep 26, 2020 at 22:20
  • Also, where do cronjob logs show up so I can try to have a look?
    – Yanick Nedderhoff
    Commented Sep 26, 2020 at 22:21
  • @YanickNedderhoff I’ll have to dig for that. I converted 100% of my jobs to launchctl so I don’t need to futz with all the setup.
    – bmike ♦
    Commented Sep 26, 2020 at 22:25
  • 1
    I’ve edited my short answer in case it helps others in hindsight. Great work with Seamus - they are ace on the command line along with a few others here :)
    – bmike ♦
    Commented Sep 27, 2020 at 18:33
  • 3
    @YanickNedderhoff: IMHO, launchctl is horribly arcane without the help of LaunchControl.
    – Seamus
    Commented Sep 27, 2020 at 18:33

You must log in to answer this question.

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