Use /etc/cron.d Over Crontab.

James Fulford
5 min readApr 6, 2022
A crontab file in a normal IDE and version-controlled, what a concept

Not all background jobs have to be in the main crontab (the one you see at EDITOR=vi crontab -e ). That crontab was all I ever knew, so the revelation of the /etc/cron.d directory was helpful, to say the least. Some benefits include:

  1. Can separate different systems into different files
    (can’t edit /etc/cron.d/database_maintenance and accidentally screw up your stock algorithm, because that’s in /etc/cron.d/stonks )
  2. Can install and update by script
    (crontab -e requires using an editor. It’s hard teaching someone how to exit an editor, never mind actually use one. Plus, who wants to sed their way through /etc/crontab? Gross.)
  3. Can version-control your scheduling config
  4. Can forget VIM forever
    (OK nerds, you can calm down now, it’s a joke)

When you make the transition, there are a few tricks you should know about:

Must Specify User

You may do this in other crontab entries, but it seems to be required for /etc/cron.d crontab snippets. I saw this on my Ubuntu machine and found FKEinternet’s great comment on the great /etc/cron.d StackExchange thread confirming the same behavior.

To do this, include a username after the 5 time specifiers, before the command. Example below specifies ubuntu:

* * * * 1-5 ubuntu cd /root/scripts && ./dump.sh

FKEinternet’s comment states no logs will be emitted if this is not addressed. But where are these logs emitted?

Check syslog for issues

If something is not acting properly, check /var/log/syslog for some error messages. This is a big file, so consider tail and grep -ing that sucker:

tail -f /var/log/syslog | grep -i cron

(-f will follow the logs, so do ctrl+c to exit — you already knew that)

(-i will ignore uppercase/lowercase when finding cron logs. Sometimes cron, sometimes CRON, even on the same server and OS.)

You will not see any logs until it is time for a job to trigger, so you might want to add a trivial job so you can verify your crontab is working:

* * * * * root date > /root/test.log
James Fulford

Harvard. Software Engineer. Entrepreneur. jamesfulford.com