Using Cron to Schedule Unix Activities

Imagine the situation. You need to schedule a program to run on an hourly basis during work hours on Monday through Friday. The program will check a database, determine whether certain conditions exist and send an email message to the appropriate personnel if necessary. There's only one problem. You don't know how to schedule a program to run automatically

Scheduling the execution of certain activities is a common requirement on many projects. For Unix-based projects, the solution is a ubiquitous program called "cron" that exists on virtually every Unix system in the world, from PC's with Linux to high-end computers from Sun and HP.

Basic Terminology

Scheduling program execution actually requires two programs: cron and crontab. The cron program runs in the background on Unix systems, waiting patiently until it needs to wake up and execute a scheduled program. The crontab program is used to edit or look at schedules. The schedule file is known as a crontab file, and a program that has been scheduled to be executed by cron is referred to as a cron job.

Editing a Crontab File

The crontab program allows users to create crontab files containing scheduling information for the program(s) that they want to execute automatically. The crontab program maintains a directory of crontab files for all users on the system, but users are not allowed direct access to this directory. To create or edit a crontab file, the user runs the crontab command with the -e option:

$ crontab -e

The program pulls in the user's existing crontab file, or creates a new one if necessary, and then passes it to an editor (such as vi or emacs) so that the user can enter scheduling information. Upon completion, the user simply exits the editor. The crontab program grabs the completed file, validates it and places it in its private directory. If the schedule fails validation then the new changes will not be copied and an error message will be provided. If the changes are validated, then crontab notifies the cron program, which is always running in the background, of the new schedule.

The default editor that crontab uses is ed, which is about as primitive as you can get. The crontab program lets users define the editor to be used. Specifically, it examines the EDITOR and VISUAL environment variables to determine which editor to use on the crontab file. If both variables are defined, the VISUAL environment variable takes precedence.

Anatomy of a Crontab File

Each line of a crontab file represents a schedule for a program that needs to be executed automatically by the cron program. Each element on the line will be separated by spaces or tabs. The cron program requires the following elements on the schedule line in the order listed below:

The command is the text string that is to be executed just as if it were being run from the Unix command-line. The other numeric parameters for the schedule can each be a single valid number, a comma-separated list of valid numbers, a range of numbers with a dash between them or an asterisk. Here are a few examples:

0 * 1-5 * * /usr/bin/myprogram -a -b -f myfile

In the example above, the minute is set to zero, the day of the week is set to 1-5 and the other schedule parameters are set to an asterisk. This program is scheduled to be run every hour on the hour during the work week, i.e. - from Monday through Friday. Note also that the command can include program options just as if it were being executed from the command line.

The asterisk means all possible values, except in one instance. Notice that there are two ways to set the day on which the program should be executed, the Day of the Week parameter and the Day of the Month parameter. If both parameters are set to an asterisk, it means every day. If one parameter has a numeric value, and the other is set to an asterisk, then the parameter with the asterisk is ignored. The above example did just this, with the Day of the Week set to 1-5, and the Day of the Month set to an asterisk.

Reality Seeps In Again

Now, armed with a knowledge of crontab files, an industrious developer sets up a cron job expecting it to run properly every hour. Instead, the hapless developer gets inundated by hourly email messages from the cron proclaiming that the program failed to execute properly.

The reason is simple. The cron job runs as if it were owned by the user that created it, with one tiny difference. The cron program doesn't do anything to set up the environment for the program being executed. That's the responsibility of the person who set up the cronjob.

By comparison, when a user logs in, the shell program that the user interacts with executes one or more files to ensure that the environment is set up for them. For example, if the user is using the Korn shell (/usr/bin/ksh), then a file called /etc/profile is executed for every user that uses the Korn shell. In addition, if a user has a file in his home directory called .profile, then that file will be executed as well.

Most programs will not run properly if their environment isn't set up properly.

There are two things to remember when creating a cron job:

1. You have to set up the environment.
2. Your program won't have a current directory.

The creator of the cron job will have to ensure that the environment variables that control program execution, tell it where to locate other programs or files, etc., get set up properly. Additionally, some programs expect required files to be located in their current directory. A program that runs as a cron job doesn't have a home directory. Files need to be referenced by their full pathname. Note that this is why the crontab file specifies the program to be executed with it's full pathname.

One common technique is to have is to have the cron job run a simple shell script. The shell script then sets up the environment properly before running the desired program. A sample shell script is shown below:

Conclusion

The Unix cron program provides an excellent way to automate the execution of regularly scheduled tasks on Unix systems. Admittedly, the process of setting up a cron job seems a little complex at first, but the complexity is easily surmounted with a little experimentation on the part of the developer. Cron also possesses the advantages of being free (if you already have the Unix system) and reliable.