Este conteúdo não está disponível no idioma selecionado.
Chapter 27. Automating System Tasks
Tasks, also known as jobs, can be configured to run automatically within a specified period of time, on a specified date, or when the system load average decreases below 0.8.
Red Hat Enterprise Linux is pre-configured to run important system tasks to keep the system updated. For example, the slocate database used by the
locate command is updated daily. A system administrator can use automated tasks to perform periodic backups, monitor the system, run custom scripts, and so on.
Red Hat Enterprise Linux comes with the following automated task utilities:
cron, anacron, at, and batch.
Every utility is intended for scheduling a different job type: while Cron and Anacron schedule recurring jobs, At and Batch schedule one-time jobs (see Section 27.1, “Cron and Anacron” and Section 27.2, “At and Batch” respectively).
27.1. Cron and Anacron
Both, Cron and Anacron, are daemons that can schedule execution of recurring tasks to a certain point in time defined by the exact time, day of the month, month, day of the week, and week.
Cron jobs can run as often as every minute. However, the utility assumes that the system is running continuously and if the system is not on at the time when a job is scheduled, the job is not executed.
On the other hand, Anacron remembers the scheduled jobs if the system is not running at the time when the job is scheduled. The job is then exectuted as soon as the system is up. However, Anacron can only run a job once a day.
27.1.1. Installing Cron and Anacron
To install Cron and Anacron, you need to install the cronie package with Cron and the cronie-anacron package with Anacron (cronie-anacron is a sub-package of cronie).
To determine if the packages are already installed on your system, issue the
rpm -q cronie cronie-anacron command. The command returns full names of the cronie and cronie-anacron packages if already installed or notifies you that the packages are not available.
To install the packages, use the
yum command in the following form:
yuminstallpackage
For example, to install both Cron and Anacron, type the following at a shell prompt:
~]# yum install cronie cronie-anacron
Note that you must have superuser privileges (that is, you must be logged in as
root) to run this command. For more information on how to install new packages in Red Hat Enterprise Linux, see Section 8.2.4, “Installing Packages”.
27.1.2. Running the Crond Service
The cron and anacron jobs are both picked by the
crond service. This section provides information on how to start, stop, and restart the crond service, and shows how to enable it in a particular runlevel. For more information on the concept of runlevels and how to manage system services in Red Hat Enterprise Linux in general, see Chapter 12, Services and Daemons.
27.1.2.1. Starting and Stopping the Cron Service
To determine if the service is running, use the command
service crond status.
To run the
crond service in the current session, type the following at a shell prompt as root:
servicecrondstart
To configure the service to be automatically started at boot time, use the following command:
chkconfigcrondon
This command enables the service in runlevel 2, 3, 4, and 5. Alternatively, you can use the Service Configuration utility as described in Section 12.2.1.1, “Enabling and Disabling a Service”.
27.1.2.2. Stopping the Cron Service
To stop the
crond service, type the following at a shell prompt as root
servicecrondstop
To disable starting the service at boot time, use the following command:
chkconfigcrondoff
This command disables the service in all runlevels. Alternatively, you can use the Service Configuration utility as described in Section 12.2.1.1, “Enabling and Disabling a Service”.
27.1.2.3. Restarting the Cron Service
To restart the
crond service, type the following at a shell prompt:
servicecrondrestart
This command stops the service and starts it again in quick succession.
27.1.3. Configuring Anacron Jobs
The main configuration file to schedule jobs is the
/etc/anacrontab file, which can be only accessed by the root user. The file contains the following:
SHELL=/bin/sh PATH=/sbin:/bin:/usr/sbin:/usr/bin MAILTO=root # the maximal random delay added to the base delay of the jobs RANDOM_DELAY=45 # the jobs will be started during the following hours only START_HOURS_RANGE=3-22 #period in days delay in minutes job-identifier command 1 5 cron.daily nice run-parts /etc/cron.daily 7 25 cron.weekly nice run-parts /etc/cron.weekly @monthly 45 cron.monthly nice run-parts /etc/cron.monthly
The first three lines define the variables that configure the environment in which the anacron tasks run:
SHELL— shell environment used for running jobs (in the example, the Bash shell)PATH— paths to executable programsMAILTO— user name of the user who receives the output of the anacron jobs by emailIf theMAILTOvariable is not defined (MAILTO=), the email is not sent.
The next two variables modify the scheduled time for the defined jobs:
RANDOM_DELAY— maximum number of minutes that will be added to thedelay in minutesvariable which is specified for each jobThe minimum delay value is set, by default, to 6 minutes.IfRANDOM_DELAYis, for example, set to12, then between 6 and 12 minutes are added to thedelay in minutesfor each job in that particular anacrontab.RANDOM_DELAYcan also be set to a value below6, including0. When set to0, no random delay is added. This proves to be useful when, for example, more computers that share one network connection need to download the same data every day.START_HOURS_RANGE— interval, when scheduled jobs can be run, in hoursIn case the time interval is missed, for example due to a power failure, the scheduled jobs are not executed that day.
The remaining lines in the
/etc/anacrontab file represent scheduled jobs and follow this format:
period in days delay in minutes job-identifier command
period in days— frequency of job execution in daysThe property value can be defined as an integer or a macro (@daily,@weekly,@monthly), where@dailydenotes the same value as integer 1,@weeklythe same as 7, and@monthlyspecifies that the job is run once a month regarless of the length of the month.delay in minutes— number of minutes anacron waits before executing the jobThe property value is defined as an integer. If the value is set to0, no delay applies.job-identifier— unique name referring to a particular job used in the log filescommand— command to be executedThe command can be either a command such asls /proc >> /tmp/procor a command which executes a custom script.
Any lines that begin with a hash sign (#) are comments and are not processed.
27.1.3.1. Examples of Anacron Jobs
The following example shows a simple
/etc/anacrontab file:
SHELL=/bin/sh PATH=/sbin:/bin:/usr/sbin:/usr/bin MAILTO=root # the maximal random delay added to the base delay of the jobs RANDOM_DELAY=30 # the jobs will be started during the following hours only START_HOURS_RANGE=16-20 #period in days delay in minutes job-identifier command 1 20 dailyjob nice run-parts /etc/cron.daily 7 25 weeklyjob /etc/weeklyjob.bash @monthly 45 monthlyjob ls /proc >> /tmp/proc
All jobs defined in this
anacrontab file are randomly delayed by 6-30 minutes and can be executed between 16:00 and 20:00.
The first defined job is triggered daily between 16:26 and 16:50 (RANDOM_DELAY is between 6 and 30 minutes; the delay in minutes property adds 20 minutes). The command specified for this job executes all present programs in the
/etc/cron.daily directory using the run-parts script (the run-parts scripts accepts a directory as a command-line argument and sequentially executes every program in the directory).
The second job executes the
weeklyjob.bash script in the /etc directory once a week.
The third job runs a command, which writes the contents of
/proc to the /tmp/proc file (ls /proc >> /tmp/proc) once a month.
27.1.4. Configuring Cron Jobs
The configuration file for cron jobs is the
/etc/crontab, which can be only modified by the root user. The file contains the following:
SHELL=/bin/bash PATH=/sbin:/bin:/usr/sbin:/usr/bin MAILTO=root HOME=/ # For details see man 4 crontabs # Example of job definition: # .---------------- 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 # | | | | | # * * * * * username command to be executed
The first three lines contain the same variable definitions as an
anacrontab file: SHELL, PATH, and MAILTO. For more information about these variables, see Section 27.1.3, “Configuring Anacron Jobs”.
In addition, the file can define the
HOME variable. The HOME variable defines the directory, which will be used as the home directory when executing commands or scripts run by the job.
The remaining lines in the
/etc/crontab file represent scheduled jobs and have the following format:
minute hour day month day of week username command
The following define the time when the job is to be run:
minute— any integer from 0 to 59hour— any integer from 0 to 23day— any integer from 1 to 31 (must be a valid day if a month is specified)month— any integer from 1 to 12 (or the short name of the month such as jan or feb)day of week— any integer from 0 to 7, where 0 or 7 represents Sunday (or the short name of the week such as sun or mon)
The following define other job properties:
username— specifies the user under which the jobs are runcommand— the command to be executedThe command can be either a command such asls /proc /tmp/procor a command which executes a custom script.
For any of the above values, an asterisk (*) can be used to specify all valid values. If you, for example, define the month value as an asterisk, the job will be executed every month within the constraints of the other values.
A hyphen (-) between integers specifies a range of integers. For example,
1-4 means the integers 1, 2, 3, and 4.
A list of values separated by commas (,) specifies a list. For example,
3, 4, 6, 8 indicates exactly these four integers.
The forward slash (/) can be used to specify step values. The value of an integer will be skipped within a range following the range with
/integer. For example, minute value defined as 0-59/2 denotes every other minute in the minute field. Step values can also be used with an asterisk. For instance, if the month value is defined as */3, the task will run every third month.
Any lines that begin with a hash sign (#) are comments and are not processed.
Users other than root can configure cron tasks with the
crontab utility. The user-defined crontabs are stored in the /var/spool/cron/ directory and executed as if run by the users that created them.
To create a crontab as a user, login as that user and type the command
crontab -e to edit the user's crontab with the editor specified in the VISUAL or EDITOR environment variable. The file uses the same format as /etc/crontab. When the changes to the crontab are saved, the crontab is stored according to user name and written to the file /var/spool/cron/username. To list the contents of your crontab file, use the crontab -l command.
Note
Do not specify the user when defining a job with the
crontab utility.
The
/etc/cron.d/ directory contains files that have the same syntax as the /etc/crontab file. Only root is allowed to create and modify files in this directory.
Note
The cron daemon checks the
/etc/anacrontab file, the /etc/crontab file, the /etc/cron.d/ directory, and the /var/spool/cron/ directory every minute for changes and the detected changes are loaded into memory. It is therefore not necessary to restart the daemon after an anacrontab or a crontab file have been changed.
27.1.5. Controlling Access to Cron
To restrict the access to Cron, you can use the
/etc/cron.allow and /etc/cron.deny files. These access control files use the same format with one user name on each line. Mind that no whitespace characters are permitted in either file.
If the
cron.allow file exists, only users listed in the file are allowed to use cron, and the cron.deny file is ignored.
If the
cron.allow file does not exist, users listed in the cron.deny file are not allowed to use Cron.
The Cron daemon (
crond) does not have to be restarted if the access control files are modified. The access control files are checked each time a user tries to add or delete a cron job.
The root user can always use cron, regardless of the user names listed in the access control files.
You can control the access also through Pluggable Authentication Modules (PAM). The settings are stored in the
/etc/security/access.conf file. For example, after adding the following line to the file, no other user but the root user can create crontabs:
-:ALL EXCEPT root :cron
The forbidden jobs are logged in an appropriate log file or, when using “crontab -e”, returned to the standard output. For more information, see
access.conf.5 (that is, man 5 access.conf).
27.1.6. Black and White Listing of Cron Jobs
Black and white listing of jobs is used to define parts of a job that do not need to be executed. This is useful when calling the run-parts script on a Cron directory, such as
/etc/cron.daily: if the user adds programs located in the directory to the job black list, the run-parts script will not execute these programs.
To define a black list, create a
jobs.deny file in the directory that run-parts scripts will be executing from. For example, if you need to omit a particular program from /etc/cron.daily, create the /etc/cron.daily/jobs.deny file. In this file, specify the names of the programs to be omitted from execution (only programs located in the same directory can be enlisted). If a job runs a command which runs the programs from the cron.daily directory, such as run-parts /etc/cron.daily, the programs defined in the jobs.deny file will not be executed.
To define a white list, create a
jobs.allow file.
The principles of
jobs.deny and jobs.allow are the same as those of cron.deny and cron.allow described in section Section 27.1.5, “Controlling Access to Cron”.
