107.2 Lesson 1
Certificate: |
LPIC-1 |
---|---|
Version: |
5.0 |
Topic: |
107 Administrative Tasks |
Objective: |
107.2 Automate system administration tasks by scheduling jobs |
Lesson: |
1 of 2 |
Introduction
One of the most important tasks of a good system administrator is to schedule jobs that must be executed on a regular basis. For example, an administrator can create and automate jobs for backups, system upgrades and to perform many other repetitive activities. To do this you can use the cron
facility, which is useful to automate periodic job scheduling.
Schedule Jobs with Cron
In Linux, cron
is a daemon that runs continuously and wakes up every minute to check a set of tables to find tasks to execute. These tables are known as crontabs and contain the so-called cron jobs. Cron is suitable for servers and systems that are constantly powered on, because each cron job is executed only if the system is running at the scheduled time. It can be used by ordinary users, each of whom has their own crontab
, as well as the root user who manages the system crontabs.
Note
|
In Linux there is also the |
User Crontabs
User crontabs are text files that manage the scheduling of user-defined cron jobs. They are always named after the user account that created them, but the location of these files depends on the distribution used (generally a subdirectory of /var/spool/cron
).
Each line in a user crontab contains six fields separated by a space:
-
The minute of the hour (0-59).
-
The hour of the day (0-23).
-
The day of the month (1-31).
-
The month of the year (1-12).
-
The day of the week (0-7 with Sunday=0 or Sunday=7).
-
The command to run.
For the month of the year and the day of the week you can use the first three letters of the name instead of the corresponding number.
The first five fields indicate when to execute the command that is specified in the sixth field, and they can contain one or more values. In particular, you can specify multiple values using:
*
(asterisk)-
Refers to any value.
,
(comma)-
Specifies a list of possible values.
-
(dash)-
Specifies a range of possible values.
/
(slash)-
Specifies stepped values.
Many distributions include the /etc/crontab
file which can be used as a reference for the layout of a cron
file. Here is an example /etc/crontab
file from a Debian installation:
SHELL=/bin/sh PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin # 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
System Crontabs
System crontabs are text files that manage the scheduling of system cron jobs and can only be edited by the root user. /etc/crontab
and all files in the /etc/cron.d
directory are system crontabs.
Most distributions also include the /etc/cron.hourly
, /etc/cron.daily
, /etc/cron.weekly
and /etc/cron.monthly
directories that contain scripts to be run with the appropriate frequency. For example, if you want to run a script daily you can place it in /etc/cron.daily
.
Warning
|
Some distributions use |
The syntax of system crontabs is similar to that of user crontabs, however it also requires an additional mandatory field that specifies which user will run the cron job. Therefore, each line in a system crontab contains seven fields separated by a space:
-
The minute of the hour (0-59).
-
The hour of the day (0-23).
-
The day of the month (1-31).
-
The month of the year (1-12).
-
The day of the week (0-7 with Sunday=0 or Sunday=7).
-
The name of the user account to be used when executing the command.
-
The command to run.
As for user crontabs, you can specify multiple values for the time fields using the *
, ,
, -
and /
operators. You may also indicate the month of the year and the day of the week with the first three letters of the name instead of the corresponding number.
Particular Time Specifications
When editing crontab files, you can also use special shortcuts in the first five columns instead of the time specifications:
@reboot
-
Run the specified task once after reboot.
@hourly
-
Run the specified task once an hour at the beginning of the hour.
@daily
(or@midnight
)-
Run the specified task once a day at midnight.
@weekly
-
Run the specified task once a week at midnight on Sunday.
@monthly
-
Run the specified task once a month at midnight on the first day of the month.
@yearly
(or@annually
)-
Run the specified task once a year at midnight on the 1st of January.
Crontab Variables
Within a crontab file, there are sometimes variable assignments defined before the scheduled tasks are declared. The environment variables commonly set are:
HOME
-
The directory where
cron
invokes the commands (by default the user’s home directory). MAILTO
-
The name of the user or the address to which the standard output and error is mailed (by default the crontab owner). Multiple comma-separated values are also allowed and an empty value indicates that no mail should be sent.
PATH
-
The path where commands can be found.
SHELL
-
The shell to use (by default
/bin/sh
).
Creating User Cron Jobs
The crontab
command is used to maintain crontab files for individual users. In particular, you can run the crontab -e
command to edit your own crontab file or to create one if it doesn’t already exist.
$ crontab -e no crontab for frank - using an empty one Select an editor. To change later, run 'select-editor'. 1. /bin/ed 2. /bin/nano < ‑‑‑‑ easiest 3. /usr/bin/emacs24 4. /usr/bin/vim.tiny Choose 1-4 [2]:
By default, the crontab
command opens the editor specified by the VISUAL
or EDITOR
environment variables so you can start editing your crontab file with the preferred editor. Some distributions, as shown in the example above, allow you to choose the editor from a list when crontab
is run for the first time.
If you want to run the foo.sh
script located in your home directory every day at 10:00 am, you can add the following line to your crontab file:
0 10 * * * /home/frank/foo.sh
Consider the following sample crontab entries:
0,15,30,45 08 * * 2 /home/frank/bar.sh 30 20 1-15 1,6 1-5 /home/frank/foobar.sh
In the first line the bar.sh
script is executed every Tuesday at 08:00 am, at 08:15 am, at 08:30 am and at 08:45 am. On the second line the foobar.sh
script is executed at 08:30 pm from Monday to Friday for the first fifteen days of January and June.
Warning
|
Although crontab files can be edited manually, it is always recommended to use the |
In addition to the -e
option mentioned above, the crontab
command has other useful options:
-l
-
Display the current crontab on standard output.
-r
-
Remove the current crontab.
-u
-
Specify the name of the user whose crontab needs to be modified. This option requires root privileges and allows the root user to edit user crontab files.
Creating System Cron Jobs
Unlike user crontabs, system crontabs are updated using an editor: therefore, you do not need to run the crontab
command to edit /etc/crontab
and the files in /etc/cron.d
. Remember that when editing system crontabs, you must specify the account that will be used to run the cron job (usually the root user).
For example, if you want to run the barfoo.sh
script located in the /root
directory every day at 01:30 am, you can open /etc/crontab
with your preferred editor and add the following line:
30 01 * * * root /root/barfoo.sh >>/root/output.log 2>>/root/error.log
In the above example, output of the job is appended to /root/output.log
, while errors are appended to /root/error.log
.
Warning
|
Unless output is redirected to a file as in the example above (or the |
Configure Access to Job Scheduling
In Linux the /etc/cron.allow
and /etc/cron.deny
files are used to set crontab
restrictions. In particular, they are used to allow or disallow the scheduling of cron jobs for different users. If /etc/cron.allow
exists, only non-root users listed within it can schedule cron jobs using the crontab
command. If /etc/cron.allow
does not exist but /etc/cron.deny
exists, only non-root users listed within this file cannot schedule cron jobs using the crontab
command (in this case an empty /etc/cron.deny
means that each user is allowed to schedule cron jobs with crontab
). If neither of these files exist, the user’s access to cron job scheduling depends on the distribution used.
Note
|
The |
An Alternative to Cron
Using systemd as the system and service manager, you can set timers as an alternative to cron
to schedule your tasks. Timers are systemd unit files identified by the .timer
suffix, and for each of these there must be a corresponding unit file which describes the unit to be activated when the timer elapses. By default, a timer
activates a service with the same name, except for the suffix.
A timer includes a [Timer]
section that specifies when scheduled jobs should run. Specifically, you can use the OnCalendar=
option to define real-time timers which work in the same way as cron jobs (they are based on calendar event expressions). The OnCalendar=
option requires the following syntax:
DayOfWeek Year-Month-Day Hour:Minute:Second
with DayOfWeek
being optional. The *
, /
and ,
operators have the same meaning as those used for cron jobs, while you can use ..
between two values to indicate a contiguous range. For DayOfWeek
specification, you can use the first three letters of the name or the full name.
Note
|
You can also define monotonic timers that activate after some time has elapsed from a specific start point (for example, when the machine was booted up or when the timer itself is activated). |
For example, if you want to run the service named /etc/systemd/system/foobar.service
at 05:30 on the first Monday of each month, you can add the following lines in the corresponding /etc/systemd/system/foobar.timer
unit file.
[Unit] Description=Run the foobar service [Timer] OnCalendar=Mon *-*-1..7 05:30:00 Persistent=true [Install] WantedBy=timers.target
Once you have created the new timer, you can enable it and start it by running the following commands as root:
# systemctl enable foobar.timer # systemctl start foobar.timer
You can change the frequency of your scheduled job, modifying the OnCalendar
value and then typing the systemctl daemon-reload
command.
Finally, if you want to view the list of active timers sorted by the time they elapse next, you can use the systemctl list-timers
command. You can add the --all
option to see the inactive timer units as well.
Note
|
Remember that timers are logged to the systemd journal and you can review the logs of the different units using the |
Instead of the longer normalized form mentioned above, you can use some special expressions which describe particular frequencies for job execution:
hourly
-
Run the specified task once an hour at the beginning of the hour.
daily
-
Run the specified task once a day at midnight.
weekly
-
Run the specified task once a week at midnight on Monday.
monthly
-
Run the specified task once a month at midnight on the first day of the month.
yearly
-
Run the specified task once a year at midnight on the first day of January.
You can see the manual pages for the full list of time and date specifications at systemd.timer(5)
.
Guided Exercises
-
For each of the following
crontab
shortcuts, indicate the corresponding time specification (i.e. the first five columns in a usercrontab
file):@hourly
@daily
@weekly
@monthly
@annually
-
For each of the following
OnCalendar
shortcuts, indicate the corresponding time specification (the longer normalized form):hourly
daily
weekly
monthly
yearly
-
Explain the meaning of the following time specifications found in a
crontab
file:30 13 * * 1-5
00 09-18 * * *
30 08 1 1 *
0,20,40 11 * * Sun
00 09 10-20 1-3 *
*/20 * * * *
-
Explain the meaning of the following time specifications used in the
OnCalendar
option of a timer file:*-*-* 08:30:00
Sat,Sun *-*-* 05:00:00
*-*-01 13:15,30,45:00
Fri *-09..12-* 16:20:00
Mon,Tue *-*-1,15 08:30:00
*-*-* *:00/05:00
Explorational Exercises
-
Assuming that you are authorized to schedule jobs with
cron
as an ordinary user, what command would you use to to create your own crontab file? -
Create a simple scheduled job that executes the
date
command every Friday at 01:00 pm. Where can you see the output of this job? -
Create another scheduled job that executes the
foobar.sh
script every minute, redirecting the output to theoutput.log
file in your home directory so that only standard error is sent to you by e-mail. -
Look at the
crontab
entry of the newly created scheduled job. Why is it not necessary to specify the absolute path of the file in which the standard output is saved? And why can you use the./foobar.sh
command to execute the script? -
Edit the previous
crontab
entry by removing the output redirection and disable the first cron job you have created. -
How can you send the output and errors of your scheduled job to the
emma
user account via e-mail? And how can you avoid sending the standard output and error via e-mail? -
Execute the command
ls -l /usr/bin/crontab
. Which special bit is set and what is its meaning?
Summary
In this lesson, you learned:
-
Use
cron
to run jobs at regular intervals. -
Manage cron jobs.
-
Configure user access to cron job scheduling.
-
Understand the role of systemd timer units as an alternative to
cron
.
The following commands and files were discussed in this lesson:
crontab
-
Maintain
crontab
files for individual users. /etc/cron.allow
and/etc/cron.deny
-
Particular files used to set
crontab
restrictions. /etc/crontab
-
System crontab file.
/etc/cron.d
-
The directory that contains system crontab files.
systemctl
-
Control the systemd system and service manager. In relation to timers, it can be used to enable and start them.
Answers to Guided Exercises
-
For each of the following
crontab
shortcuts, indicate the corresponding time specification (the first five columns in acrontab
file):@hourly
0 * * * *
@daily
0 0 * * *
@weekly
0 0 * * 0
@monthly
0 0 1 * *
@annually
0 0 1 1 *
-
For each of the following
OnCalendar
shortcuts, indicate the corresponding time specification (the longer normalized form):hourly
*-*-* *:00:00
daily
*-*-* 00:00:00
weekly
Mon *-*-* 00:00:00
monthly
*-*-01 00:00:00
yearly
*-01-01 00:00:00
-
Explain the meaning of the following time specifications for a
crontab
file:30 13 * * 1-5
At 01:30 pm every day of the week from Monday to Friday
00 09-18 * * *
Every day and every hour from 09 am to 06 pm
30 08 1 1 *
At 08:30 am on the first day of January
0,20,40 11 * * Sun
Every Sunday at 11:00 am, 11:20 am and 11:40 am
00 09 10-20 1-3 *
At 09:00 am from the 10th to the 20th of January, February and March
*/20 * * * *
Every twenty minutes
-
Explain the meaning of the following time specifications used in the
OnCalendar
option of a timer file:*-*-* 08:30:00
Every day at 08:30 am
Sat,Sun *-*-* 05:00:00
At 05:00 am on Saturday and Sunday
*-*-01 13:15,30,45:00
At 01:15 pm, 01:30 pm and 01:45 pm on the first day of the month
Fri *-09..12-* 16:20:00
At 04:20 pm every Friday in September, October, November and December
Mon,Tue *-*-1,15 08:30:00
At 08.30 am on the first or fifteenth day of each month only if the day is a Monday or Tuesday
*-*-* *:00/05:00
Every five minutes
Answers to Explorational Exercises
-
Assuming that you are authorized to schedule jobs with
cron
as an ordinary user, what command would you use to to create your own crontab file?dave@hostname ~ $ crontab -e no crontab for dave - using an empty one Select an editor. To change later, run 'select-editor'. 1. /bin/ed 2. /bin/nano < ---- easiest 3. /usr/bin/emacs24 4. /usr/bin/vim.tiny Choose 1-4 [2]:
-
Create a simple scheduled job that executes the
date
command every Friday at 01:00 pm. Where can you see the output of this job?00 13 * * 5 date
The output is mailed to the user; to view it, you can use the
mail
command. -
Create another scheduled job that executes the
foobar.sh
script every minute, redirecting the output to theoutput.log
file in your home directory so that only standard error is sent to you by e-mail.*/1 * * * * ./foobar.sh >> output.log
-
Look at the
crontab
entry of the newly created scheduled job. Why is it not necessary to specify the absolute path of the file in which the standard output is saved? And why can you use the./foobar.sh
command to execute the script?cron
invokes the commands from the user’s home directory, unless another location is specified by theHOME
environment variable within thecrontab
file. For this reason, you can use the relative path of the output file and run the script with./foobar.sh
. -
Edit the previous
crontab
entry by removing the output redirection and disable the first cron job you have created.#00 13 * * 5 date */1 * * * * ./foobar.sh
To disable a cron job, you can simply comment the corresponding line within the
crontab
file. -
How can you send the output and errors of your scheduled job to the
emma
user account via e-mail? And how can you avoid sending the standard output and error via e-mail?To send the standard output and error to
emma
, you must set theMAILTO
environment variable in yourcrontab
file as follows:MAILTO="emma"
To tell
cron
that no mail should be sent, you can assign an empty value to theMAILTO
environment variable.MAILTO=""
-
Execute the command
ls -l /usr/bin/crontab
. Which special bit is set and what is its meaning?$ ls -l /usr/bin/crontab -rwxr-sr-x 1 root crontab 25104 feb 10 2015 /usr/bin/crontab
The
crontab
command has the SGID bit set (thes
character instead of the executable flag for the group), which means that it is executed with the privileges of the group (thuscrontab
). This is why ordinary users can edit theircrontab
file using thecrontab
command. Note that many distributions have file permissions set such thatcrontab
files can only be edited via thecrontab
command.