Scheduling with crontab

Backups at 2 a.m., log clean-ups every Sunday, a health check every five minutes: these are jobs for cron. The daemon crond wakes up once a minute, reads each user's crontab (cron table) and runs every line whose time matches. You never edit the table files directly; the crontab command installs, lists and removes them for you.

The five time fields

# ┌──────── minute       (0-59)
# │  ┌───── hour         (0-23)
# │  │ ┌─── day of month (1-31)
# │  │ │ ┌─ month        (1-12)
# │  │ │ │ ┌ day of week (0-6, 0 = Sunday)
# │  │ │ │ │
 30  2 * * * /root/bin/backup.sh

Each line has five time fields and then the command. * means "every". A field can also hold a list (1,15), a range (1-5) or a step (*/10, every ten). A line runs when all fields match the current time, so 30 2 * * * means "at 02:30 every day". Lines starting with # are comments.

Managing your crontab

In this VM there is one preparation step: the tables live in /var/spool/cron/crontabs, and that directory does not exist yet (crontab complains can't change directory). Create it once with mkdir -p. Then:

~% mkdir -p /var/spool/cron/crontabs
~% echo '30 2 * * * /root/bin/backup.sh' | crontab -
~% crontab -l
30 2 * * * /root/bin/backup.sh
~% (crontab -l; echo '*/15 * * * * /root/bin/check.sh >> /tmp/check.log 2>&1') | crontab -
~% crontab -l
30 2 * * * /root/bin/backup.sh
*/15 * * * * /root/bin/check.sh >> /tmp/check.log 2>&1
~% crontab -r
~% crontab -l
crontab: can't open 'root': No such file or directory

crontab FILE installs FILE as your whole table, and crontab - reads it from standard input. Both replace the existing table, which is why adding a line uses the subshell trick from lesson 96: list the current table, append the new line, and feed the result back. crontab -e opens the table in vi (lessons 28 and 29) and installs it when you save; crontab -l lists it; crontab -r removes it entirely, without asking. As root, -u USER manages another user's table.

The daemon, and jobs that work alone

A crontab does nothing unless crond is running. Check with pidof crond or ps | grep crond; start it with crond -b (background). For debugging, crond -f -l 0 stays in the foreground and logs everything it does. Remember that jobs run without you: no terminal, a minimal PATH, and the home directory as working directory. So use absolute paths for every command and file, and redirect output to a log (>> /tmp/job.log 2>&1) or it is simply lost.