RHCSA Rapid Track
Course update
An updated version of this course is available that uses a newer version of Red Hat Enterprise Linux in the lab environment. Therefore, the RHEL 9.0 version of the lab environment will retire on December 31, 2024. Please complete any work in this lab environment before it is removed on December 31, 2024. For the most up-to-date version of this course, we recommend moving to the RHEL 9.3 version.
Abstract
| Goal | Schedule tasks to automatically execute in the future. |
| Objectives |
|
| Sections |
|
Recurring jobs are scheduled to run repeatedly.
Red Hat Enterprise Linux systems provide the crond daemon, which is enabled and started by default.
The crond daemon reads multiple configuration files: one per user, and a set of system-wide files.
Each user has a personal file that they edit with the crontab -e command.
When executing recurring jobs, these configuration files provide detailed control to users and administrators.
If the scheduled job is not written to use redirection, then the crond daemon emails any generated output or errors to the job owner.
Use the crontab command to manage scheduled jobs.
The following list shows the commands that a local user can use to manage their jobs:
Table 7.1. Examples Of The crontab Command
| Command | Intended use |
|---|---|
crontab -l
| List the jobs for the current user. |
crontab -r
| Remove all jobs for the current user. |
crontab -e
| Edit jobs for the current user. |
crontab
| Remove all jobs, and replace them with jobs that are read from filename.
This command uses stdin input when no file is specified. |
A privileged user might use the crontab command -u option to manage jobs for another user.
The crontab command is never used to manage system jobs, and using the crontab commands as the root user is not recommended due to the ability to exploit personal jobs that are configured to run as root.
Configure such privileged jobs as described in the later section that describes recurring system jobs.
The crontab -e command invokes the vim editor by default unless the EDITOR environment variable is set for another editor.
Each job must use a unique line in the crontab file.
Follow these recommendations for valid entries when writing recurring jobs:
Empty lines for ease of reading
Comments on lines that start with the number sign (
#)Environment variables with a
NAME=valueformat, which affects all lines after the line where they are declared
Standard variable settings include the SHELL variable, to declare the shell that is used for interpreting the remaining lines of the crontab file.
The MAILTO variable determines who should receive the emailed output.
Note
The ability to send an email requires additional system configuration for a local mail server or an SMTP relay.
The fields in the crontab file appear in the following order:
Minutes
Hours
Day of month
Month
Day of week
Command
The command executes when the Day of month or Day of week fields use the same value other than the * character.
For example, to run a command on the 11th day of every month, and every Friday at 12:15 (24-hour format), use the following job format:
15 12 11 * Fri commandThe first five fields all use the same syntax rules:
Use the
*character to execute in every possible instance of the field.A number to specify the number of minutes or hours, a date, or a day of the week. For days of the week,
0equals Sunday,1equals Monday,2equals Tuesday, and so on.7also equals Sunday.Use
x-yfor a range, which includes thexandyvalues.Use
x,yfor lists. Lists might include ranges as well, for example,5,10-13,17in theMinutescolumn, for a job to run at 5, 10, 11, 12, 13, and 17 minutes past the hour.The
*/xindicates an interval ofx; for example,*/7in theMinutescolumn runs a job every seven minutes.
Additionally, 3-letter English abbreviations are used for months or days of the week, for example, Jan, Feb, and Mon, Tue.
The last field contains the full command with options and arguments to execute with the default shell.
If the command contains an unescaped percentage sign (%), then that percentage sign is treated as a newline character, and everything after the percentage sign passes to the command as stdin input.
The following job executes the /usr/local/bin/yearly_backup command at exactly 09:00 on 3 February, every year.
February is represented as the number 2 in the example, because it is the second month of the year.
0 9 3 2 * /usr/local/bin/yearly_backup
The following job sends an email that contains the Chime word to the owner of this job every five minutes between and including 09:00 and 16:00, but only on each Friday in July.
*/5 9-16 * Jul 5 echo "Chime"
The preceding 9-16 range of hours means that the job timer starts at the ninth hour (09:00) and continues until the end of the sixteenth hour (16:59).
The job starts executing at 09:00 with the last execution at 16:55, because five minutes after 16:55 is 17:00, which is beyond the given scope of hours.
If a range is specific for the hours instead of a single value, then all hours within the range will match.
Therefore, with the hours of 9-16, this example matches every five minutes from 09:00 through 16:55.
Note
This example job sends the output as an email, because crond recognizes that the job allowed output to go to the STDIO channel without redirection.
Because cron jobs run in a background environment without an output device (known as a controlling terminal), crond buffers the output and creates an email to send it to the specified user in the configuration.
For system jobs, the email is sent to the root account.
The following job runs the /usr/local/bin/daily_report command every working day (Monday to Friday) two minutes before midnight.
58 23 * * 1-5 /usr/local/bin/daily_report
The following job executes the mutt command to send the Checking in mail message to the developer@example.com recipient every working day (Monday to Friday), at 9 AM.
0 9 * * 1-5 mutt -s "Checking in" developer@example.com % Hi there, just checking in.