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.
Schedule commands to run on a repeating schedule with the system crontab file and directories.
System administrators often need to run recurring jobs.
It is best to run these jobs from system accounts rather than from user accounts.
Schedule these jobs with system-wide crontab files instead of with the crontab command.
Job entries in the system-wide crontab files are similar to the users' crontab entries.
The system-wide crontab files have an extra field before the command field to specify the user that runs the command.
The /etc/crontab file has a syntax diagram in the comments.
SHELL=/bin/bash PATH=/sbin:/bin:/usr/sbin:/usr/bin MAILTO=root # 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 # | | | | | # * * * * * user-name command to be executed
The /etc/crontab file and other files in the /etc/cron.d/ directory define the recurring system jobs.
Always create custom crontab files in the /etc/cron.d/ directory to schedule recurring system jobs.
Place the custom crontab file in the /etc/cron.d directory to prevent a package update from overwriting the /etc/crontab file.
Packages that require recurring system jobs place their crontab files in the /etc/cron.d/ directory with the job entries.
Administrators also use this location to group related jobs into a single file.
The crontab system also includes repositories for scripts to run every hour, day, week, and month.
These repositories are placed in the /etc/cron.hourly/, /etc/cron.daily/, /etc/cron.weekly/, and /etc/cron.monthly/ directories.
These directories contain executable shell scripts, not crontab files.
Note
Use the chmod +x command to make a script executable.
A script must be executable to run.script_name
The run-parts command also runs the daily, weekly, and monthly jobs from the /etc/anacrontab configuration file.
The /etc/anacrontab file ensures that scheduled jobs always run and are not skipped accidentally because the system was turned off or hibernated.
For example, when a system job that runs daily was not executed at a specified time because the system was rebooting, then the job is completed when the system becomes ready.
A delay might occur before the job starts, if specified in the Delay in minutes parameter in the /etc/anacrontab file.
Files in the /var/spool/anacron/ directory determine the daily, weekly, and monthly jobs.
When the crond daemon starts a job from the /etc/anacrontab file, it updates the timestamps of those files.
With this timestamp, you can determine the last time that the job executed.
The syntax of the /etc/anacrontab file is different from the regular crontab configuration files.
The /etc/anacrontab file contains four fields per line, as follows.
-
Period in days Defines the interval in days for the job to run on a recurring schedule. This field accepts an integer or a macro value. For example, the macro
@dailyis equivalent to the1integer, which executes the job daily. Similarly, the macro@weeklyis equivalent to the7integer, which executes the job weekly.-
Delay in minutes Defines the time that the
cronddaemon must wait before it starts the job.-
Job identifier Identifies the unique name of the job in the log messages.
-
Command The command to be executed.
The /etc/anacrontab file also contains environment variable declarations with the NAME=value syntax.
The START_HOURS_RANGE variable specifies the time interval for the jobs to run.
Jobs do not start outside this range.
When a job does not run within this time interval on a particular day, then the job must wait until the next day for execution.
The systemd timer unit activates another unit of a different type (such as a service), whose unit name matches the timer unit name.
The timer unit allows timer-based activation of other units.
The systemd timer unit logs timer events in system journals for easier debugging.
The sysstat package provides the systemd timer unit, called the sysstat-collect.timer service, to collect system statistics every 10 minutes.
The following output shows the contents of the /usr/lib/systemd/system/sysstat-collect.timer configuration file.
...output omitted...
[Unit]
Description=Run system activity accounting tool every 10 minutes
[Timer]
OnCalendar=*:00/10
[Install]
WantedBy=sysstat.serviceThe OnCalendar=*:00/10 option signifies that this timer unit activates the corresponding sysstat-collect.service unit every 10 minutes.
You might specify more complex time intervals.
For example, a 2022-04-* 12:35,37,39:16 value against the OnCalendar option causes the timer unit to activate the corresponding service unit at the 12:35:16, 12:37:16, and 12:39:16 times, every day during April 2022.
You might also specify relative timers with the OnUnitActiveSec option.
For example, with the OnUnitActiveSec=15min option, the timer unit triggers the corresponding unit to start 15 minutes after the last time that the timer unit activated its corresponding unit.
Important
Do not modify any units in the configuration files under the /usr/lib/systemd/system directory, because the systemd unit overrides the configuration changes in that file.
Create a copy of the configuration file in the /etc/systemd/system directory, and then modify the copied file to prevent any update to the provider package from overriding the changes.
If two files exist with the same name in the /usr/lib/systemd/system and /etc/systemd/system directories, then the systemd timer unit parses the file in the /etc/systemd/system directory.
After you change the timer unit configuration file, use the systemctl daemon-reload command to ensure that the systemd timer unit loads the changes.
[root@host ~]# systemctl daemon-reloadAfter reloading the systemd daemon configuration, use the systemctl command to activate the timer unit.
[root@host ~]# systemctl enable --now <unitname>.timer