The crond Service

The name of the cron daemon is crond. Normally it is started automatically when your system starts up. You can set this feature using redhat-config-services or chkconfig, as described in Chapter 20. The following example starts the crond service automatically whenever you boot the system.

chkconfig crond on

You can also start and stop the crond service manually, which you may want to do for emergency maintenance or during upgrades. Use the service command and the stop option to shut down the service, and the start option to run it again:

service crond stop

crontab Entries

A crontab entry has six fields: the first five are used to specify the time for an action, while the last field is the action itself. The first field specifies minutes (0–59), the second field specifies the hour (0–23), the third field specifies the day of the month (1–31), the fourth field specifies the month of the year (1–12, or month prefixes like Jan and Sep), and the fifth field specifies the day of the week (0–6, or day prefixes like Wed and Fri), starting with 0 as Sunday. In each of the time fields, you can specify a range, a set of values, or use the asterisk to indicate all values. For example, 1–5 for the day-of-week field specifies Monday through Friday. In the hour field, 8, 12, and 17 would specify 8 A.M., 12 noon, and 5 P.M. An * in the month-of-year field indicates every month. The format of a crontab field follows:

minute  hour  day-month  month  day(s)-week  task

The following example backs up the projects directory at 2:00 A.M. every weekday:

0 2 * * 1-5   tar cf /home/backp /home/projects

The same entry is listed here again using prefixes for the month and weekday:

0 2 * * Mon-Fri tar cf /home/backp /home/projects

To specify particular months, days, weeks, or hours, you can list them individually, separated by commas. For example, to perform the previous task on Sunday, Wednesday, and Friday, you could use 0,3,5 in the day-of-week field, or their prefix equivalents, Sun,Wed,Fri.

0 2 * * 0,3,5   tar cf /home/backp /home/projects

Cron also supports comments. A comment is any line beginning with a # sign.

# Weekly backup for Chris's projects
0 2 * * Mon-Fri  tar cf /home/backp /home/projects

cron Environment Variables

The cron service also lets you define environment variables for use with tasks performed. Red Hat defines variables for SHELL, PATH, HOME, and MAILTO. SHELL designates the shell to use tasks, in this case the bash shell. PATH lists the directories where programs and scripts can be found. This example lists the standard directories, /usr/bin and /bin, as well as the system directories reserved for system applications, /usr/sbin and /sbin. MAILTO designates to whom the results of a task are to be mailed. By default, these are mailed to the user who schedules it, but you can have the results sent to a specific user, such as the administrator's e-mail address, or an account on another system in a network. HOME is the home directory for a task, in this case the top directory.

SHELL=/bin/bash
PATH=/sbin:/bin:/usr/sbin:/usr/bin
MAILTO=root
HOME=/

cron.d Directory

On a heavily used system, the /etc/crontab file can become crowded easily. There may also be instances where certain entries require different variables. For example, you may need to run some task under a different shell. To help better organize your crontab tasks, you can place crontab entries in files within the cron.d directory. The files in the cron.d directory all contain crontab entries of the same format as /etc/crontab. They may be given any name. They are treated as added crontab files, with cron checking them for the task to run. For example, Red Hat installs a sysstat file in the cron.d that contains crontab entries to run tools to gather system statistics.

crontab Command

You use the crontab command to install your entries into a crontab file. To do this, first create a text file and type your crontab entries. Save this file with any name you want, such as mycronfile. Then, to install these entries, enter crontab and the name of the text file. The crontab command takes the contents of the text file and creates a crontab file in the /var/spool/cron directory, adding the name of the user who issued the command. In the following example, the root user installs the contents of the mycronfile as the root's crontab file. This creates a file called /var/spool/cron/root. If a user named justin installed a crontab file, it would create a file called /var/spool/cron/justin. You can control use of the crontab command by regular users with the /etc/cron.allow file. Only users with their names in this file can create crontab files of their own. Conversely, the /etc/cron.deny file lists those users denied use of the cron tool, preventing them from scheduling tasks. If neither file exists, access is denied to all users. If a user is not in a /etc/cron.allow file, access is denied. However, if the /etc/cron.allow file does not exist, and the /etc/cron.deny file does, then all users not listed in /etc/cron.deny are automatically allowed access.

# crontab mycronfile

cron Editing

Never try to edit your crontab file directly. Instead, use the crontab command with the -e option. This opens your crontab file in the /var/spool/cron directory with the standard text editor, such as Vi. crontab uses the default editor as specified by the EDITOR shell environment variable. To use a different editor for crontab, change the default editor by assigning the editor's program name to the EDITOR variable and exporting that variable. Normally, the editor variable is set in the /etc/profile script. Running crontab with the -l option displays the contents of your crontab file, and the -r option deletes the entire file. Invoking crontab with another text file of crontab entries overwrites your current crontab file, replacing it with the contents of the text file.

Organizing Scheduled Tasks

You can organize administrative cron tasks into two general groups: common administrative tasks that can be run at regular intervals, or specialized tasks that need to be run at a unique time. Unique tasks can be run as entries in the /etc/crontab file, as described in the next section. Common administrative tasks, though they can be run from the /etc/crontab file, are better organized into specialized cron directories. Within such directories, each task is placed in its own shell script that will invoke the task when run. For example, there may be several administrative tasks that all need to be run each week on the same day, say if maintenance for a system is scheduled on a Sunday morning. For these kinds of tasks, cron provides several specialized directories for automatic daily, weekly, monthly, and yearly tasks. Each contains a cron prefix and a suffix for the time interval. The /etc/cron.daily directory is used for tasks that need to be performed every day, whereas weekly tasks can be placed in the /etc/cron.weekly directory. The cron directories are listed in Table 27-2.

Running cron Directory Scripts

Each directory contains scripts that are all run at the same time. The scheduling for each group is determined by an entry in the /etc/crontab file. The actual execution of the scripts is performed by the /usr/bin/run-parts script, which runs all the scripts and programs in a given directory. Scheduling for all the tasks in a given directory is handled by an entry in the /etc/crontab file. Red Hat provides entries with designated times, which you may change for your own needs. The default Red Hat crontab file is shown here, with times for running scripts in the different cron directories. Here you can see that most scripts are run at about 4 A.M. either daily (4:02), Sunday (4:22), or the first day of each month (4:42). Hourly ones are run one minute after the hour.

SHELL=/bin/bash
PATH=/sbin:/bin:/usr/sbin:/usr/bin
MAILTO=root
HOME=/
# run-parts
01 * * * * root run-parts /etc/cron.hourly
02 4 * * * root run-parts /etc/cron.daily
22 4 * * 0 root run-parts /etc/cron.weekly
42 4 1 * * root run-parts /etc/cron.monthly

Keep in mind though that these are simply directories that contain executable files. The actual scheduling is performed by the entries in the /etc/crontab file. For example, if the weekly field in the cron.weekly crontab entry is changed to * instead of 0, and the monthly field to 1 (22 4 1 * * instead of 22 4 * * 0), tasks in the cron.weekly file would end up running monthly instead of weekly.

cron Directory Names

The names used for these directories are merely conventions. They have no special meaning to the cron daemon. You could, in fact, create your own directory, place scripts within it, and schedule run-parts to run those scripts at a given time. In the next example, scripts placed in the /etc/cron.mydocs directory will run at 12 noon every Wednesday.

* 12 * * 3 root run-parts /etc/cron.mydocs

Anacron

For a system that may normally be shut down during times that cron is likely to run, you may want to supplement cron with anacron. anacron activates only when scheduled tasks need to be executed. For example, if a system is shut down on a weekend when cron jobs are scheduled, then the jobs will not be performed. anacron, however, checks to see what jobs need to be performed when the system is turned on again, and then runs them. It is designed only for jobs that run daily or weekly.

For anacron jobs, you place crontab entries in the /etc/anacrontab file. For each scheduled task, you specify the number of intervening days when it is executed (7 is weekly, 30 is monthly), the time of day it is run (numbered in minutes), a description of the task, and the command to be executed. For backups, the command would be tar operation. You can use redhat-config-services to turn on the anacron service or have it start up automatically at boot time.