| Previous | Table of Contents | Next |
by Tim Parker
Automating tasks is one of the best ways to keep a system running smoothly. If you take all the repetitive system administration commands you need to run regularly and have them execute in the background without your direct involvement, system administration becomes much less onerous and bothersome. It is for this simple reason that the utilities cron and at were developed. Both allow you to execute commands at specified times automatically, without requiring any attention from you.
The cron (short for chronograph) utility is designed to allow commands to execute at specific times without anyone directly initiating them. To do this, Linux loads cron as a clock daemon when the system starts up. (The cron utility is usually run from an rc file entry and can be disabled by commenting out the line that starts it.) When operating, cron reads the days and times it is supposed to execute a task from a file called the crontab file.
Whenever one of the crontab file’s entry day and time specification matches the system’s date and time, the cron daemon starts to execute the command. The cron utility doesn’t just execute the task once: Whenever the day and time match, the task is re-run. This continues until the cron utility is terminated or the crontab file is modified. The automatic execution of tasks means that cron is ideal for automating regular system administration tasks, tape backups, database reorganization, and general file cleanups (such as emptying log files and queues).
On most systems, access to cron is limited to the system administrator only, although it can easily be activated for some or all users on your system. System administrators control who can send processes to be executed by cron through one of two different files, often called /usr/lib/cron/cron.allow or /usr/lib/cron/cron.deny. Many Linux systems use the names /etc/cron.d/cron.allow and /etc/cron.d/cron.deny. Both files have one username (which matches the entry in /etc/passwd) per line.
The file /usr/lib/cron/cron.allow (or /etc/cron.d/cron.allow) can contain a list of all usernames that are allowed to use cron. For example, this file allows only the logins tparker, yvonne, and bill (as well as the superuser) to submit anything to cron
tparker yvonne bill
Alternatively, the file /usr/lib/cron/cron.deny can contain a list of usernames that are not allowed to use cron. For example, the following file allows anyone except the logins walter and anne to use cron
walter anne
By using one of these optional files, system administrators can control cron usage. If neither the cron.allow nor cron.deny file exists, only the superuser (root) can submit processes to cron. In order to allow all users to use cron, create an empty cron.deny file.
Note:
You may be wondering why you would want to use cron when you could enter these commands at the shell prompt. That’s true, but you also have to remember to do them, you need to be present to type them, and you have to wait for them to terminate. The cron system provides a way to place the most frequently used routines into a file and then forget about them. It’s much easier than going through the steps of a long list of commands for backups, cleaning up directories, and so on.
To instruct cron to process commands on particular days and at specific times, you use a utility program called crontab. The crontab program reads a file that contains the details of what you want cron to do and queues it. In addition, crontab performs several other administrative tasks, such as displaying your current cron task list, removing the list, and adding new tasks.
The file that crontab reads to determine what you want to submit to cron is usually named crontab for convenience, although it could be called anything. The crontab utility has a command option that allows you to specify the filename to be treated as instructions. Otherwise, the crontab utility reads the default filename crontab.
The crontab instruction file has a simple structure, although it takes a few minutes to get used to it. The file consists of one complete line for each process to be submitted which specifies when to run the process and what command to execute. The format of each line is as follows:
minute hour day-of-month month-of-year day-of-week command
A sample two-line extract from a crontab file looks like this:
20 1 * * * /usr/bin/calendar - 0 2 * * * /bin/organize_data
Each line in the crontab file has six columns separated by white space (spaces or tabs). The columns from left to right are
This rather strange (at first glance) format is necessary to allow you to specify exactly when a process is to run. Without the five different categories for days and time, you can’t precisely specify an event that occurs at random times during a month. As you will see in a moment, these columns are quite easy to complete.
The last column contains the command or script filename that is to be executed. A script that is to be executed can have many lines and call other scripts, or can be only a single line. The first process is initiated when the crontab file matches the day and time. It is important to provide an absolute pathname to the command (even if it’s in your PATH), as the cron jobs do not inherit your environment variables and thus don’t know where to look for commands. Also, you must have execute permission for the utility or script. If you are submitting crontab files as a user (not superuser), you must have file permissions or ownership set to allow you normal access, as cron executes the processes as though you owned them.
| Previous | Table of Contents | Next |