Objectives

After completing this section, you should be able to schedule commands to run on a repeating schedule using the system crontab file and directories.

Describing Recurring System Jobs

System administrators often need to run recurring jobs. Best practice is to run these jobs from system accounts rather than from user accounts. That is, do not schedule to run these jobs using the crontab command, but instead use system-wide crontab files. Job entries in the system-wide crontab files are similar to those of the users' crontab entries, excepting only that the system-wide crontab files have an extra field before the command field; the user under whose authority the command should run.

The /etc/crontab file has a useful syntax diagram in the included comments.

 # 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 ...
# |  |  |  |  |
# *  *  *  *  * user-name  command to be executed

Recurring system jobs are defined in two locations: the /etc/crontab file, and files within the /etc/cron.d/ directory. You should always create your custom crontab files under the /etc/cron.d directory to schedule recurring system jobs. Place the custom crontab file in /etc/cron.d to protect it from being overwritten if any package update occurs to the provider of /etc/crontab, which may overwrite the existing contents in /etc/crontab. Packages that require recurring system jobs place their crontab files in /etc/cron.d/ containing the job entries. Administrators also use this location to group related jobs into a single file.

The crontab system also includes repositories for scripts that need to run every hour, day, week, and month. These repositories are directories called /etc/cron.hourly/, /etc/cron.daily/, /etc/cron.weekly/, and /etc/cron.monthly/. Again, these directories contain executable shell scripts, not crontab files.

A command called run-parts called from the /etc/cron.d/0hourly file runs the /etc/cron.hourly/* scripts. The run-parts command also runs the daily, weekly, and monthly jobs, but it is called from a different configuration file called /etc/anacrontab.

The purpose of /etc/anacrontab is to make sure that important jobs always run, and not skipped accidentally because the system was turned off or hibernating when the job should have been executed. For example, if a system job that runs daily was not executed last time it was due because the system was rebooting, the job is executed when the system becomes ready. However, there may be a delay of several minutes in starting the job depending on the value of the Delay in minutes parameter specified for the job in /etc/anacrontab.

There are different files in /var/spool/anacron/ for each of the daily, weekly, and monthly jobs to determine if a particular job has run. When crond starts a job from /etc/anacrontab, it updates the time stamps of those files. The same time stamp is used to determine when a job was last run. The syntax of /etc/anacrontab is different from the regular crontab configuration files. It contains exactly four fields per line, as follows.

The /etc/anacrontab file also contains environment variable declarations using the syntax NAME=value. Of special interest is the variable START_HOURS_RANGE, which specifies the time interval for the jobs to run. Jobs are not started outside of this range. If on a particular day, a job does not run within this time interval, the job has to wait until the next day for execution.

Introducing Systemd Timer

With the advent of systemd in Red Hat Enterprise Linux 7, a new scheduling function is now available: systemd timer units. A 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. For easier debugging, systemd logs timer events in system journals.

Sample Timer Unit

The sysstat package provides a systemd timer unit called sysstat-collect.timer to collect system statistics every 10 minutes. The following output shows the configuration lines of /usr/lib/systemd/system/sysstat-collect.timer.

...output omitted...
[Unit]
Description=Run system activity accounting tool every 10 minutes

[Timer]
OnCalendar=*:00/10

[Install]
WantedBy=sysstat.service

The parameter OnCalendar=*:00/10 signifies that this timer unit activates the corresponding unit (sysstat-collect.service) every 10 minutes. However, you can specify more complex time intervals. For example, a value of 2019-03-* 12:35,37,39:16 against the OnCalendar parameter causes the timer unit to activate the corresponding service unit at 12:35:16, 12:37:16, and 12:39:16 every day throughout the entire month of March, 2019. You can also specify relative timers using parameters such as OnUnitActiveSec. For example, the OnUnitActiveSec=15min option causes the timer unit to trigger the corresponding unit 15 minutes after the last time the timer unit activated its corresponding unit.

After you change the timer unit configuration file, use the systemctl daemon-reload command to ensure that systemd is aware of the changes. This command reloads the systemd manager configuration.

[root@host ~]# systemctl daemon-reload

After you reload the systemd manager configuration, use the following systemctl command to activate the timer unit.

[root@host ~]# systemctl enable --now <unitname>.timer