Red Hat [Electronic resources] : The Complete Reference Enterprise Linux Fedora Edition؛ The Complete Reference نسخه متنی

Scheduling Tasks: cron

Scheduling regular maintenance tasks, such as backups, is managed by the cron service on Linux, implemented by a cron daemon. A daemon is a continually running server that constantly checks for certain actions to take. These tasks are listed in the crontab file. The cron daemon constantly checks the user's crontab file to see if it is time to take these actions. Any user can set up a crontab file of his or her own. The root user can set up a crontab file to take system administrative actions, such as backing up files at a certain time each week or month.

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.