Linux Professional Institute Learning Logo.
Skip to main content
  • Home
    • All Resources
    • LPI Learning Materials
    • Become a Contributor
    • Publishing Partners
    • Become a Publishing Partner
    • About
    • FAQ
    • Contributors
    • Roadmap
    • Contact
  • LPI.org
107.2 Lesson 1
Topic 105: Shells and Shell Scripting
105.1 Customize and use the shell environment
  • 105.1 Lesson 1
  • 105.1 Lesson 2
  • 105.1 Lesson 3
105.2 Customize or write simple scripts
  • 105.2 Lesson 1
  • 105.2 Lesson 2
Topic 106: User Interfaces and Desktops
106.1 Install and configure X11
  • 106.1 Lesson 1
106.2 Graphical Desktops
  • 106.2 Lesson 1
106.3 Accessibility
  • 106.3 Lesson 1
Topic 107: Administrative Tasks
107.1 Manage user and group accounts and related system files
  • 107.1 Lesson 1
  • 107.1 Lesson 2
107.2 Automate system administration tasks by scheduling jobs
  • 107.2 Lesson 1
  • 107.2 Lesson 2
107.3 Localisation and internationalisation
  • 107.3 Lesson 1
Topic 108: Essential System Services
108.1 Maintain system time
  • 108.1 Lesson 1
  • 108.1 Lesson 2
108.2 System logging
  • 108.2 Lesson 1
  • 108.2 Lesson 2
108.3 Mail Transfer Agent (MTA) basics
  • 108.3 Lesson 1
108.4 Manage printers and printing
  • 108.4 Lesson 1
Topic 109: Networking Fundamentals
109.1 Fundamentals of internet protocols
  • 109.1 Lesson 1
  • 109.1 Lesson 2
109.2 Persistent network configuration
  • 109.2 Lesson 1
  • 109.2 Lesson 2
109.3 Basic network troubleshooting
  • 109.3 Lesson 1
  • 109.3 Lesson 2
109.4 Configure client side DNS
  • 109.4 Lesson 1
Topic 110: Security
110.1 Perform security administration tasks
  • 110.1 Lesson 1
110.2 Setup host security
  • 110.2 Lesson 1
110.3 Securing data with encryption
  • 110.3 Lesson 1
  • 110.3 Lesson 2
  1. Topic 107: Administrative Tasks
  2. 107.2 Automate system administration tasks by scheduling jobs
  3. 107.2 Lesson 1

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 anacron facility, which is suitable for systems that can be powered off (such as desktops or laptops). It can only be used by root. If the machine is off when the anacron jobs must be executed, they will run the next time the machine is powered on. anacron is out of scope for the LPIC-1 certification.

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 /etc/cron.d/hourly, /etc/cron.d/daily, /etc/cron.d/weekly and /etc/cron.d/monthly. Always remember to check for the correct directories in which to place scripts you would like cron to run.

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 crontab command. The permissions on the crontab files usually only allow them to be edited via the crontab command.

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 MAILTO variable is set to a blank value), all output from a cron job will be sent to the user via e-mail. A common practice is to redirect standard output to /dev/null (or to a file for later review if necessary) and to not redirect standard error. This way the user will be notified immediately by e-mail of any errors.

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 /etc/cron.allow and /etc/cron.deny files contain of a list of usernames, each on a separate line.

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 journalctl command. Also remember that if you are acting as an ordinary user, you need to use the --user option of the systemctl and journalctl commands.

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 Excercises

  1. For each of the following crontab shortcuts, indicate the corresponding time specification (i.e. the first five columns in a user crontab file):

    @hourly

    @daily

    @weekly

    @monthly

    @annually

  2. For each of the following OnCalendar shortcuts, indicate the corresponding time specification (the longer normalized form):

    hourly

    daily

    weekly

    monthly

    yearly

  3. 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 * * * *

  4. 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 Excercises

  1. 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?

  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?

  3. Create another scheduled job that executes the foobar.sh script every minute, redirecting the output to the output.log file in your home directory so that only standard error is sent to you by e-mail.

  4. 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?

  5. Edit the previous crontab entry by removing the output redirection and disable the first cron job you have created.

  6. 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?

  7. 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

  1. For each of the following crontab shortcuts, indicate the corresponding time specification (the first five columns in a crontab file):

    @hourly

    0 * * * *

    @daily

    0 0 * * *

    @weekly

    0 0 * * 0

    @monthly

    0 0 1 * *

    @annually

    0 0 1 1 *

  2. 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

  3. 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

  4. 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

  1. 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]:
  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.

  3. Create another scheduled job that executes the foobar.sh script every minute, redirecting the output to the output.log file in your home directory so that only standard error is sent to you by e-mail.

    */1 * * * * ./foobar.sh >> output.log
  4. 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 the HOME environment variable within the crontab file. For this reason, you can use the relative path of the output file and run the script with ./foobar.sh.

  5. 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.

  6. 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 the MAILTO environment variable in your crontab file as follows:

    MAILTO="emma"

    To tell cron that no mail should be sent, you can assign an empty value to the MAILTO environment variable.

    MAILTO=""
  7. 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 (the s character instead of the executable flag for the group), which means that it is executed with the privileges of the group (thus crontab). This is why ordinary users can edit their crontab file using the crontab command. Note that many distributions have file permissions set such that crontab files can only be edited via the crontab command.

© 2020 Linux Professional Insitute Inc. All rights reserved. Visit the Learning Materials website: https://learning.lpi.org
This work is licensed under the Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International License.

Next Lesson

107.2 Automate system administration tasks by scheduling jobs (107.2 Lesson 2)

Read next lesson

© 2020 Linux Professional Insitute Inc. All rights reserved. Visit the Learning Materials website: https://learning.lpi.org
This work is licensed under the Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International License.

LPI is a non-profit organization.

Linux Professional Institute (LPI) is the global certification standard and career support organization for open source professionals. With more than 200,000 certification holders, it's the world’s first and largest vendor-neutral Linux and open source certification body. LPI has certified professionals in over 180 countries, delivers exams in multiple languages, and has hundreds of training partners.

Our purpose is to enable economic and creative opportunities for everybody by making open source knowledge and skills certification universally accessible.

  • LinkedIn
  • flogo-RGB-HEX-Blk-58 Facebook
  • Twitter
  • Contact Us
  • Privacy and Cookie Policy

Spot a mistake or want to help improve this page? Please let us know.

© Copyright 1999-2020 The Linux Professional Institute Inc. All rights reserved.