For those already familiar with unix-like operating systems, cron may be old news, while new users with limited command-line experience may never have heard of it. Cron is one of those system-level services that can be indispensable when you figure out what it does and how to use it.
In my typical mode somewhere between casual- and power-user, I have put cron to great use in running parts of my system beyond the stock configuration. For me, cron’s most critical role has been that of backup-scheduler.
What is cron?
Essentially, cron is a task scheduler—it hangs out in the background, waiting to run the tasks you define in its configuration file(s), called crontabs. The most basic use is to have a single user crontab containing a list of all the user’s scheduled tasks.
It might be worth pointing out that this is outside of the general system startup routines, which have their own configuration and process, and which aren’t so much scheduled as they are event-driven. Cron is used, however, to schedule regular system cleanup and maintenance routines in the background.
Using crontab
On my system, and I assume, most systems, cron is already setup and ready to go. There are really only a couple commands you need to know to manage your crontab.
crontab -l lists the current user’s crontab file, displaying all the currently scheduled tasks.
crontab -e will load the current user’s crontab file into your shell’s default editor. You may make any changes you need to make, save the file, and cron will automatically reload it. If you’ve introduced a syntax error, cron will fail to parse the file and will report the error to you—until you fix the error, your cron jobs will not run.
crontab Configuration
You can find more detailed information about the crontab syntax elsewhere, but basically, you can schedule a task by minute and hour, and by day of month, month, or day of week. For example, you can schedule a task to run at 16:12 on the 28th day of the 2nd month, or at 16:12 every Thursday. You could conceivably schedule a task to run every minute of every hour of every day, of every month. You generally can’t, however, schedule tasks by the second, nor can you schedule tasks that only run once*. Though you could conceivably schedule a task that would only run 13 times in 400 years, if you scheduled it on a Sunday, Tuesday, or Thursday that was also the 29th day of the 2nd month.
As for tasks, you are almost unlimited in what you can do. Each crontab rule will take a full bash command string, as long the command fits on a single line. More often than not, I will have cron run scripts that I’ve written, but I have used a few straight bash commandlines in the past. It may help to know that you can put multiple commands on a single bash commandline if you separate them with a semicolon.
Real-world Examples
As I mostly use cron to control backups, here are two quick examples:
50 4 8,28 * * ~/scripts/websiteBackup coffeemonk.com 1> /dev/null 2>&1
websiteBackup is a script I cobbled together to use wget to pull down a regular full-site backup (via FTP) of my various websites. I have cron run this at different times for each site depending on how often they’re updated, and usually staggered by anywhere from 5 to 20 minutes depending on each site’s overall size. In this case, I have cron set to backup coffeemonk.com on the 8th and 28th days of every month, at 4:50am.
25 3,18 * * * unison music >/tmp/unicronout 2>&1; ~/scripts/eunisonerrs
I back up my music files to a local file server using the unison synchronization utility. I have a few different unison scripts for backing up different parts of my system. This particular entry runs my unison music sync script every day at 3:25am and 6:25pm.
Digging Deeper
So far, I have been able to accomplish everything using the single user crontab. I have, however, seen mention of daily, weekly, and monthly crontabs, which appear to be connected to anacron—another system service that is dependent on cron.
To schedule a job that needs to run once at a specific time in the future, the command at might be your answer. I haven’t used it extensively, but it seems to have great potential.
If you need to schedule system-level tasks to run at startup/shutdown, you’ll want to look into init or ubuntu’s new upstart system, which is an event-driven, rather than time-based scheduler.
Really, this is only a surface-level introduction to task scheduling, and to cron in particular, so if you have a different or better way of handling this stuff, or if you have some more real-world examples you’d like to share, please leave a comment.
* it seems some implementations of cron offer support for seconds and/or years in the crontab file.