crontab -- good times

Sometimes it's apparently the simplest, most potential helpful concepts which are the most poorly executed. Adding a printer, calling a script at a certain time each day. For those that configure these things for a living, I'm sure it's easy --- the rest of us look forward to the day basic functions won't take a week to configure.

So...crontab. A simple concept which requires threading through a weird syntax, and kludgy daemon and script file relationships until one finally gets it to work on their particular installation. Here's what worked on a recent install of Arch. First the unintuitive, unhelpful crontab syntax:

Example of job definition:
.---------------- minute (0 - 59)
| .------------- hour (0 - 23)
| | .---------- day of month (1 - 31)
| | | .------- month (1 - 12) OR jan,feb,mar,apr ...
| | | | .---- day of week (0 - 6) (Sunday=0 or 7)
| | | | |
* * * * * command to be executed

Let's say I want to delete a file every night at midnight; let's use the common example of .local/share/recently-used.xbel. I go to $ crontab -e to access my crontab file and create the job line:

0 0 * * * /usr/bin/rm -rf /home/foo/.local/share/recently-used*

So zero hour, and the asterisks mean "every". Every day of the week, every day of the month, at zero hour this command will be executed. The other asterisk, the one at the end of the file to be deleted? Another "feature" of crontab is it appears to ignore commands with file extensions, so I replace any file extensions with asterisks or leave them off entirely. I've also found that the last line has to be a newline, so that, following my command above, I need to make a hard return in the file. Note also that I used the hard path to the rm command, and to the file to be deleted. This is because of the common PATH issues with crontab. Finally, if crontab has the wrong syntax, it loads without errors but simply doesn't perform its tasks.

Even if one manages to get the insanely finnicky crontab in a proper syntax for running, it still is unlikely to run. Why? Daemon problems. Their are at least 5 different cron daemons available, instead of one. All of them behave differently. There is crond, cronie, fcron, anacron, and cronie-without-anacron, for example. More horrible design work around this critical function. At least one of them must be running for the crontab to execute.

systemd

Systemd uses timers.

$ systemctl list-timers