Use /etc/cron.d Over Crontab.
--
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:
- 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
) - 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 tosed
their way through/etc/crontab
? Gross.) - Can version-control your scheduling config
- 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