Advanced Job Scheduling With Cron

The cron daemon is a core component of any Unix-like operating system. On the surface, cron is a scheduler, meant to run a command at regular intervals. However, if we dig a little deeper into the configuration options, we find that we can configure cron to be as detailed and granular as we need. If you need a script to run every seven minutes, five days a week, between the hours of 8AM and 4PM, cron has you covered.

Cron’s pedigree reaches back to the earliest days of Unix. The first version was written by Brian Kernigan and simply read the config file once a minute and decided if there was anything to do at the time. Today’s cron is more sophisticated, but not unnecessarily so. As happens in open source projects over time, the code has been forked, extended, abandoned, forked again, cleaned, and modified throughout the years. CentOS 5 shipped with a variant written by Paul Vixie called “vixie cron”, which appears to have been abandoned in favor of a fork named cronie for CentOS 6. The switch was also discussed by the openSUSE project:

Currently our default cron daemon is vixie-cron, upstream of this project looks dead and we have 20 patches in our package without chance to push it to upstream. This state leads to disorder and many patches use different syntax or style. Possible solutions are: create our new openSUSE fork and move it to git or svn, other solution is switch to other existing newer cron project (bcron,fcron,cronie) and merge our patches with them. Switching to cronie seems to be the best choice. Cronie is a fork from vixie-cron and it is the default cron daemon in Fedora.

The crontab program manages individual users cron configuration files. On CentOS, the user crontabs are kept in /var/spool/cron, one file per user. These files are not meant to be edited directly, but through the crontab command using crontab -e. However, there are also several directories under /etc where cron configurations can exist as well. The system crontab is kept in /etc/crontab, and it calls the run-parts script to process the cron.hourly, cron.daily, cron.weekly, and cron.monthly directories under /etc. The files inside of these directories are simply shell scripts or executables meant to be run on a regular, simple schedule. Under /etc there is also a cron.d directory, inside this directory are mini-crontabs, configuration files with the syntax of a crontab, but do not belong in either a user crontab file or in one of the regularly scheduled crontab files.

The syntax of a cron configuration file can be difficult to memorize unless you are creating new jobs to run fairly often. Getting back to our example above, to run a script every seven minutes, five days a week, between 8AM and 4PM, the configuration would look like this:

*/7 8,9,10,11,12,13,14,15,16 * * 1,2,3,4,5 /bin/echo "Hello World" 

The default /etc/crontab file on CentOS 6 contains a good illustration of how the configuration is built.

.---------------- 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) OR sun,mon,tue,wed,thu,fri,sat
|  |  |  |  |
*  *  *  *  * user-name command to be executed

Each field is separated by a space. Each field can contain multiple values, either separated by a comma, as in my example, or a dash to include all of the values between the two characters. An asterisk means “all values”, so in my example above, the “Hello World” echo would run on all days of the month, every month of the year, but I further specify only to run the command if the day is not Saturday or Sunday.

While cron is not a full fledged “enterprise” job scheduling system, one could easily see how it could be used to string jobs together. For example, you could kick off a script once a minute that looked for the existence of a file in a particular place, and if it existed, perform some action on the file. Or, have the script look for a value in a file, and act on that value. Cron’s flexibility in scheduling opens it up to a wealth of automation possibilities. As with many aspects of open source, you are only limited by your imagination.