Cron how to use

How I use cron in Linux

Internet Archive Book Images. Modified by Opensource.com. CC BY-SA 4.0

One of the challenges (among the many advantages) of being a sysadmin is running tasks when you’d rather be sleeping. For example, some tasks (including regularly recurring tasks) need to run overnight or on weekends, when no one is expected to be using computer resources. I have no time to spare in the evenings to run commands and scripts that have to operate during off-hours. And I don’t want to have to get up at oh-dark-hundred to start a backup or major update.

Instead, I use two service utilities that allow me to run commands, programs, and tasks at predetermined times. The cron and at services enable sysadmins to schedule tasks to run at a specific time in the future. The at service specifies a one-time task that runs at a certain time. The cron service can schedule tasks on a repetitive basis, such as daily, weekly, or monthly.

In this article, I’ll introduce the cron service and how to use it.

Common (and uncommon) cron uses

I use the cron service to schedule obvious things, such as regular backups that occur daily at 2 a.m. I also use it for less obvious things.

The crond daemon is the background service that enables cron functionality.

The cron service checks for files in the /var/spool/cron and /etc/cron.d directories and the /etc/anacrontab file. The contents of these files define cron jobs that are to be run at various intervals. The individual user cron files are located in /var/spool/cron, and system services and applications generally add cron job files in the /etc/cron.d directory. The /etc/anacrontab is a special case that will be covered later in this article.

Using crontab

New cron files are empty, so commands must be added from scratch. I added the job definition example below to my own cron files, just as a quick reference, so I know what the various parts of a command mean. Feel free to copy it for your own use.

The crontab command is used to view or edit the cron files.

The first three lines in the code above set up a default environment. The environment must be set to whatever is necessary for a given user because cron does not provide an environment of any kind. The SHELL variable specifies the shell to use when commands are executed. This example specifies the Bash shell. The MAILTO variable sets the email address where cron job results will be sent. These emails can provide the status of the cron job (backups, updates, etc.) and consist of the output you would see if you ran the program manually from the command line. The third line sets up the PATH for the environment. Even though the path is set here, I always prepend the fully qualified path to each executable.

There are several comment lines in the example above that detail the syntax required to define a cron job. I’ll break those commands down, then add a few more to show you some more advanced capabilities of crontab files.

This line in my /etc/crontab runs a script that performs backups for my systems.

This line runs my self-written Bash shell script, rsbu, that backs up all my systems. This job kicks off at 1:01 a.m. (01 01) every day. The asterisks (*) in positions three, four, and five of the time specification are like file globs, or wildcards, for other time divisions; they specify «every day of the month,» «every month,» and «every day of the week.» This line runs my backups twice; one backs up to an internal dedicated backup hard drive, and the other backs up to an external USB drive that I can take to the safe deposit box.

The following line sets the hardware clock on the computer using the system clock as the source of an accurate time. This line is set to run at 5:03 a.m. (03 05) every day.

This line sets the hardware clock using the system time as the source.

I was using the third and final cron job (commented out) to perform a dnf or yum update at 04:25 a.m. on the first day of each month, but I commented it out so it no longer runs.

This line used to perform a monthly update, but I’ve commented it out.

Other scheduling tricks

Now let’s do some things that are a little more interesting than these basics. Suppose you want to run a particular job every Thursday at 3 p.m.:

This line runs mycronjob.sh every Thursday at 3 p.m.

Or, maybe you need to run quarterly reports after the end of each quarter. The cron service has no option for «The last day of the month,» so instead you can use the first day of the following month, as shown below. (This assumes that the data needed for the reports will be ready when the job is set to run.)

This cron job runs quarterly reports on the first day of the month after a quarter ends.

The following shows a job that runs one minute past every hour between 9:01 a.m. and 5:01 p.m.

Sometimes you want to run jobs at regular times during normal business hours.

I have encountered situations where I need to run a job every two, three, or four hours. That can be accomplished by dividing the hours by the desired interval, such as */3 for every three hours, or 6-18/3 to run every three hours between 6 a.m. and 6 p.m. Other intervals can be divided similarly; for example, the expression */15 in the minutes position means «run the job every 15 minutes.»

This cron job runs every five minutes during every hour between 8 a.m. and 5:58 p.m.

One thing to note: The division expressions must result in a remainder of zero for the job to run. That’s why, in this example, the job is set to run every five minutes (08:05, 08:10, 08:15, etc.) during even-numbered hours from 8 a.m. to 6 p.m., but not during any odd-numbered hours. For example, the job will not run at all from 9 p.m. to 9:59 a.m.

I am sure you can come up with many other possibilities based on these examples.

Limiting cron access

More Linux resources

Regular users with cron access could make mistakes that, for example, might cause system resources (such as memory and CPU time) to be swamped. To prevent possible misuse, the sysadmin can limit user access by creating a /etc/cron.allow file that contains a list of all users with permission to create cron jobs. The root user cannot be prevented from using cron.

By preventing non-root users from creating their own cron jobs, it may be necessary for root to add their cron jobs to the root crontab. «But wait!» you say. «Doesn’t that run those jobs as root?» Not necessarily. In the first example in this article, the username field shown in the comments can be used to specify the user ID a job is to have when it runs. This prevents the specified non-root user’s jobs from running as root. The following example shows a job definition that runs a job as the user «student»:

If no user is specified, the job is run as the user that owns the crontab file, root in this case.

cron.d

The directory /etc/cron.d is where some applications, such as SpamAssassin and sysstat, install cron files. Because there is no spamassassin or sysstat user, these programs need a place to locate cron files, so they are placed in /etc/cron.d.

The /etc/cron.d/sysstat file below contains cron jobs that relate to system activity reporting (SAR). These cron files have the same format as a user cron file.

The sysstat package installs the /etc/cron.d/sysstat cron file to run programs for SAR.

The sysstat cron file has two lines that perform tasks. The first line runs the sa1 program every 10 minutes to collect data stored in special binary files in the /var/log/sa directory. Then, every night at 23:53, the sa2 program runs to create a daily summary.

Scheduling tips

Some of the times I set in the crontab files seem rather random—and to some extent they are. Trying to schedule cron jobs can be challenging, especially as the number of jobs increases. I usually have only a few tasks to schedule on each of my computers, which is simpler than in some of the production and lab environments where I have worked.

One system I administered had around a dozen cron jobs that ran every night and an additional three or four that ran on weekends or the first of the month. That was a challenge, because if too many jobs ran at the same time—especially the backups and compiles—the system would run out of RAM and nearly fill the swap file, which resulted in system thrashing while performance tanked, so nothing got done. We added more memory and improved how we scheduled tasks. We also removed a task that was very poorly written and used large amounts of memory.

The crond service assumes that the host computer runs all the time. That means that if the computer is turned off during a period when cron jobs were scheduled to run, they will not run until the next time they are scheduled. This might cause problems if they are critical cron jobs. Fortunately, there is another option for running jobs at regular intervals: anacron.

anacron

The anacron program performs the same function as crond, but it adds the ability to run jobs that were skipped, such as if the computer was off or otherwise unable to run the job for one or more cycles. This is very useful for laptops and other computers that are turned off or put into sleep mode.

As soon as the computer is turned on and booted, anacron checks to see whether configured jobs missed their last scheduled run. If they have, those jobs run immediately, but only once (no matter how many cycles have been missed). For example, if a weekly job was not run for three weeks because the system was shut down while you were on vacation, it would be run soon after you turn the computer on, but only once, not three times.

The anacron program provides some easy options for running regularly scheduled tasks. Just install your scripts in the /etc/cron.[hourly|daily|weekly|monthly] directories, depending how frequently they need to be run.

How does this work? The sequence is simpler than it first appears.

The contents of /etc/cron.d/0hourly cause the shell scripts located in /etc/cron.hourly to run.

The contents of /etc/anacrontab file runs the executable files in the cron.[daily|weekly|monthly] directories at the appropriate times.

Instead of placing complete Bash programs in the cron.X directories, I install them in the /usr/local/bin directory, which allows me to run them easily from the command line. Then I add a symlink in the appropriate cron directory, such as /etc/cron.daily.

The anacron program is not designed to run programs at specific times. Rather, it is intended to run programs at intervals that begin at the specified times, such as 3 a.m. (see the START_HOURS_RANGE line in the script just above) of each day, on Sunday (to begin the week), and on the first day of the month. If any one or more cycles are missed, anacron will run the missed jobs once, as soon as possible.

Shortcuts

The /etc/anacrontab file shown above shows us a clue to how we can use shortcuts for a few specific and common times. These single-word time shortcuts can be used to replace the five fields usually used to specify times. The @ character is used to identify shortcuts to cron. The list below, taken from the crontab(5) man page, shows the shortcuts with their equivalent meanings.

These shortcuts can be used in any of the crontab files, such as those in /etc/cron.d.

More on setting limits

I use most of these methods for scheduling tasks to run on my computers. All those tasks are ones that need to run with root privileges. It’s rare in my experience that regular users really need a cron job. One case was a developer user who needed a cron job to kick off a daily compile in a development lab.

It is important to restrict access to cron functions by non-root users. However, there are circumstances when a user needs to set a task to run at pre-specified times, and cron can allow them to do that. Many users do not understand how to properly configure these tasks using cron and they make mistakes. Those mistakes may be harmless, but, more often than not, they can cause problems. By setting functional policies that cause users to interact with the sysadmin, individual cron jobs are much less likely to interfere with other users and other system functions.

It is possible to set limits on the total resources that can be allocated to individual users or groups, but that is an article for another time.

For more information, the man pages for cron, crontab, anacron, anacrontab, and run-parts all have excellent information and descriptions of how the cron system works.

This article was originally published in November 2017 and has been updated to include additional information.

How to Use the Cron Task Scheduler

Author: Josh Amata

Last Updated: Fri, Oct 15, 2021

Introduction

This guide explains how to use Cron and Anacron to schedule tasks.

Prerequisites

What is Cron?

The cron command-line utility is a built-in job scheduler on Unix-like operating systems such as Linux, used for running processes such as commands, scripts, etc at a scheduled time. Tasks such as system maintenance, backup automation, or more repetitive ones like downloading files and emails, running web scrapers, etc can be scheduled to run using cron.

The background service responsible for providing this cron functionality is the crond daemon. Cron’s actions are defined by crontab files, which are special configuration files that specify what shell commands to run periodically on a given schedule.

The cron service searches for crontab files in the following directories:

Cron wakes each minute and examines all stored crontabs, inspecting each command to see if it should be run in the current minute. It also checks each minute to see if its spool directory’s modtime has changed, and if it has, cron will then examine the modtime on all crontabs and reload those that have changed, which negates the need to restart the cron service whenever a crontab file is modified.

Each user can have their crontab file.

Anatomy of a Crontab file

Cron uses a special format to read lines from crontab configuration files before executing the command.

Each line in this format represents a cron job:

Adding that line to a crontab file schedules a script do_something.sh to run by 17:30 (i.e 5:30p.m) on the 7th day of every month, anyday.
Each field should be separated by a space.

Note: the asterisk (*) is a wildcard character that signifies every possible value allowed. You could also specify a range of values by separating with a dash, or several distinct values by separating by a comma.

You can set up a default environment using the following variables:

Note: you should define these variables at the top of the crontab file, like:

These variables should be set specific to a given user because cron does not provide an environment of any kind.

Adding a Cron Job

To add a cron job, you must edit the crontab configuration file for the current user. To do this, enter the command in a terminal window:

Or to edit the crontab for a different user, enter the command (with sudo/root privileges):

A text file like the following will be opened for you to edit:

Simply add your cron job in the format described earlier to the file:

Now save, and close your editor. You have successfully added a cron job for the specified user.
Cron jobs added this way, will by default be saved under /var/spool/cron/crontabs.

More examples of cron jobs:

Run command every day by 3am, 9am and 12pm:

Run command hourly on the 16th day of the 12th month (December):

Run command 15 minutes past every hour between midnight and 6am, on every Sunday:

Cron also allows the following special strings as shortcuts:

For example, to run a command daily, simply use:

Listing Cron Jobs

To list all the cron jobs running on your system without opening crontab configuration files, simply enter the command:

Restricting Cron Access

As a sysadmin, you might want to restrict regular users from creating cron jobs, due to possible misuse. To achieve this, you can limit user access by creating a /etc/cron.d/cron.allow file that contains the list of users separated by newlines with permission to create cron jobs.
Or alternatively, create a /etc/cron.d/cron.deny file containing a list of users to deny permission to create cron jobs (also separate users with newlines).

Add the following lines:

Now save and close the file.

Note: the root user cannot be denied permission to use cron this way.

Alternatively, you can also run cron jobs for other users using this format as root.

Introducing Anacron

In the event of a system shutdown or sleep mode which causes cron to miss its scheduled jobs, those jobs will be skipped over as cron assumes the system is running continuously. This may not be optimal behavior, as you could miss out on important jobs such as data or email backups.

Anacron reads a list of jobs from a special configuration file /etc/anacrontab, which contains the list of jobs that anacron controls. Each job entry specifies a period in days, a delay in minutes, a unique job identifier, and a shell command:

The period specifies if the job has been run in the last n days, the delay specifies how long anacron should wait before running the job’s shell command, while the job identifier is a distinctive name for the job when writing to log files.

Adding Jobs To Anacron

Unlike cron which is built-in, anacron must be installed. For ubuntu and debian systems, simply run the following command as sudo/root to install:

To add jobs to anacron, open the configuration file /etc/anacrontab, it should look like this:

Add entries in this format:

This will run our data-backup.sh script as soon as possible if it hasn’t been run in 30 days(a month) with a delay of 15 minutes before execution. This job will be identified by data-backup1 in log files.

Anacron isn’t designed to run scripts at specific times, rather it runs scripts at intervals beginning at specific times. You can fix time intervals by defining a special variable START_HOURS_RANGE before the job entries:

This will cause anacron to do jobs only between the hours 4-23 (4 a.m-11 p.m).

Anacron supports shortcuts as we saw in cron earlier to specify the period. The previous entry could be written as:

Automated Options

Anacron also provides some simplified options to run regularly scheduled tasks. You can simply install your scripts in the following directories depending on your need, and anacron will handle the rest:

Conclusion

In this guide, you have learned about the cron scheduler and how it works, how to schedule cron jobs, and scheduling anacron jobs.

Further Reading

Check out the man pages for cron, crontab and anacron to see more.

Ubuntu Documentation

Introduction

Cron is a system daemon used to execute desired tasks (in the background) at designated times.

A crontab file is a simple text file containing a list of commands meant to be run at specified times. It is edited using the crontab command. The commands in the crontab file (and their run times) are checked by the cron daemon, which executes them in the system background.

Each user (including root) has a crontab file. The cron daemon checks a user’s crontab file regardless of whether the user is actually logged into the system or not.

To display the on-line help for crontab enter:

or further information is available from the OpenGroup specifications.

Starting to Use Cron

To use cron for tasks meant to run only for your user profile, add entries to your own user’s crontab file. To edit the crontab file enter:

Edit the crontab using the format described in the next sections. Save your changes. (Exiting without saving will leave your crontab unchanged.) To display the on-line help describing the format of the crontab file enter:

Commands that normally run with administrative privileges (i.e. they are generally run using sudo) should be added to the root crontab. To edit the root crontab enter:

Crontab Lines

Each line has five time-and-date fields, followed by a command, followed by a newline character (‘\n’). The fields are separated by spaces. The five time-and-date fields cannot contain spaces. The five time-and-date fields are as follows: minute (0-59), hour (0-23, 0 = midnight), day (1-31), month (1-12), weekday (0-6, 0 = Sunday).

The above example will run /usr/bin/somedirectory/somecommand at 4:01am on January 1st plus every Monday in January.

An asterisk (*) can be used so that every instance (every hour, every weekday, every month, etc.) of a time period is used.

The above example will run /usr/bin/somedirectory/somecommand at 4:01am on every day of every month.

Comma-separated values can be used to run more than one instance of a particular command within a time period. Dash-separated values can be used to run a command continuously.

The above example will run /usr/bin/somedirectory/somecommand at 01 and 31 past the hours of 4:00am and 5:00am on the 1st through the 15th of every January and June.

The «/usr/bin/somedirectory/somecommand» text in the above examples indicates the task which will be run at the specified times. It is recommended that you use the full path to the desired commands as shown in the above examples. Enter which somecommand in the terminal to find the full path to somecommand. The crontab will begin running as soon as it is properly edited and saved.

You may want to run a script some number of times per time unit. For example if you want to run it every 10 minutes use the following crontab entry (runs on minutes divisible by 10: 0, 10, 20, 30, etc.)

which is also equivalent to the more cumbersome

Cron also offers some special strings, which can be used in place of the five time-and-date fields:

string

meaning

Run once, at startup.

Run once a year, «0 0 1 1 *».

(same as @yearly)

Run once a month, «0 0 1 * *».

Run once a week, «0 0 * * 0».

Run once a day, «0 0 * * *».

(same as @daily)

Run once an hour, «0 * * * *».

The above example will execute /path/to/executable1 when the system starts.

For more information on special strings enter «man 5 crontab».

Crontab Options

After you exit from the editor, the modified crontab is checked for errors and, if there are no errors, it is installed automatically. The file is stored in /var/spool/cron/crontabs but should only be edited using the crontab command.

Allowing/Denying User-Level Cron

If the /etc/cron.allow file exists, then users must be listed in it in order to be allowed to run the crontab command. If the /etc/cron.allow file does not exist but the /etc/cron.deny file does, then users must not be listed in the /etc/cron.deny file in order to run crontab.

In the case where neither file exists, the default on current Ubuntu (and Debian, but not some other Linux and UNIX systems) is to allow all users to run jobs with crontab.

No cron.allow or cron.deny files exist in a standard Ubuntu install, so all users should have cron available by default, until one of those files is created. If a blank cron.deny file has been created, that will change to the standard behavior users of other operating systems might expect: cron only available to root or users in cron.allow.

Note, userids on your system which do not appear in /etc/shadow will NOT have operational crontabs, if you desire to enter a user in /etc/passwd, but NOT /etc/shadow that user’s crontab will never run. Place an entry in /etc/shadow for the user with a * for the password crypt, eg:

Further Considerations

Crontab commands are generally stored in the crontab file belonging to your user account (and executed with your user’s level of permissions). If you want to regularly run a command requiring administrative permissions, edit the root crontab file:

Depending on the commands being run, you may need to expand the root users PATH variable by putting the following line at the top of the root crontab file:

It is sensible to test that your cron jobs work as intended. One method for doing this is to set up the job to run a couple of minutes in the future and then check the results before finalising the timing. You may also find it useful to put the commands into script files that log their success or failure, for example:

If your machine is regularly switched off, you may also be interested in at and anacron, which provide other approaches to scheduled tasks. For example, anacron offers simple system-wide directories for running commands hourly, daily, weekly, and monthly. Scripts to be executed in said times can be placed in /etc/cron.hourly/, /etc/cron.daily/, /etc/cron.weekly/, and /etc/cron.monthly/. All scripts in each directory are run as root, and a specific order to running the scripts can be specified by prefixing the scripts’ filenames with numbers (see the man page for run‑parts for more details). Although the directories contain periods in their names, run‑parts will not accept a file name containing a period and will fail silently when encountering them (bug #38022). Either rename the file or use a symlink (without a period) to it instead (see, for example, python + cron without login? and Problems with Hourly Cron Job).

Common Problems

Edits to a user’s crontab and the cron jobs run are all logged by default to /var/log/syslog and that’s the first place to check if things are not running as you expect.

If a user was not allowed to execute jobs when their crontab was last edited, just adding them to the allow list won’t do anything. The user needs to re-edit their crontab after being added to cron.allow before their jobs will run.

Note that user-specific crontabs (including the root crontab) do not specify the user name after the date/time fields. If you accidentally include the user name in a user-specific crontab, the system will try to run the user name as a command.

Cron jobs may not run with the environment, in particular the PATH, that you expect. Try using full paths to files and programs if they’re not being located as you expect.

The «%» character is used as newline delimiter in cron commands. If you need to pass that character into a script, you need to escape it as «\%».

If you’re having trouble running a GUI application using cron, see the GUI Applications section below.

Two Other Types of Crontab

The crontab files discussed above are user crontabs. Each of the above crontabs is associated with a user, even the root crontab, which is associated with the root user. There are two other types of crontab, with syntax as follows:

Note that the only difference from the syntax of the user crontabs is that the line specifies the user to run the job as.

The first type is as follows. As mentioned above anacron uses the run‑parts command and /etc/cron.hourly, /etc/cron.weekly, and /etc/cron.monthly directories. However anacron itself is invoked from the /etc/crontab file. This file could be used for other cron commands, but probably shouldn’t be. Here’s an example line from a fictitious /etc/crontab:

This would run Rusty’s command script as user rusty from his home directory. However, it is not usual to add commands to this file. While an experienced user should know about it, it is not recommended that you add anything to /etc/crontab. Apart from anything else, this could cause a problem if the /etc/crontab file is affected by updates! Rusty could lose his command.

The second type is to be found in the directory /etc/cron.d. This directory can contain crontab files. The directory is often used by packages, and the crontab files allow a user to be associated with the commands in them.

Example: Instead of adding a line to /etc/crontab, which Rusty knows is not a good idea, he might well add a file to the directory /etc/cron.d with the name rusty, containing his cron line above. This would not be affected by updates but is a well known location.

You may not need to look at /etc/crontab or /etc/cron.d, let alone edit them by hand. But an experienced user should perhaps know about them and that the packages that he/she installs may use these locations for their crontabs.

GUI Applications

It is possible to run gui applications via cronjobs. This can be done by telling cron which display to use.

The env DISPLAY=:0 portion will tell cron to use the current display (desktop) for the program «gui_appname».

And if you have multiple monitors, don’t forget to specify on which one the program is to be run. For example, to run it on the first screen (default screen) use :

The env DISPLAY=:0.0 portion will tell cron to use the first screen of the current display for the program «gui_appname».

Note: GUI users may prefer to use gnome-schedule (aka «Scheduled tasks») to configure GUI cron jobs. In gnome-schedule, when editing a GUI task, you have to select «X application» in a dropdown next to the command field.

Note: In Karmic(9.10), you have to enable X ACL for localhost to connect to for GUI applications to work.

Crontab Example

Save your changes and exit the editor.

Crontab will let you know if you made any mistakes. The crontab will be installed and begin running if there are no errors. That’s it. You now have a cronjob setup to run updatedb, which updates the slocate database, every morning at 4:45.

How Anacron is Set Up

On Ubuntu 9.10 (and presumably, on later versions), anacron seems to be set up as follows:

There is a Upstart task, located in /etc/init/anacron.conf, which runs all the jobs in /etc/anacrontab. It is set to run on startup.

There is a cron.d file (/etc/cron.d/anacron) which causes the Upstart task to be started every day at 7:30 AM.

There is a file /etc/apm/event.d/anacron, which causes the Upstart task to be started when a laptop is plugged in to A/C power, or woken up.

In the system crontab (/etc/crontab), if anacron is not execuatable, run‑parts is used to run the files in cron.daily, cron.weekly, and cron.monthly at 6:25 AM, 6:47 AM and 6:52 AM, respectively.

In /etc/anacrontab, run‑parts is used to run cron.daily 5 minutes after anacron is started, and cron.weekly after 10 minutes (once a week), and cron.monthly after 15 (once a month).

Within the cron.daily, weekly, and monthly directories ( /etc/cron.daily, etc.) there is a 0anacron file that sets the timestamps for anacron, so it will know they have been run, even if it didn’t run them.

So it appears anacron is run on every startup, wake up, plug-in, and at 7:30 AM every day. Looking at the respective Changelogs and package databases, it looks like this setup is directly from Debian, and hasn’t been changed since at least 2009.

Alternatives to Cron

Some hosting companies don’t allow access to cron, but there are websites offering alternative ways of scheduling jobs (free or paid-for). Here are some examples:

CronHowto (последним исправлял пользователь gweatherby 2016-11-20 17:36:12)

The material on this wiki is available under a free license, see Copyright / License for details
You can contribute to this wiki, see Wiki Guide for details

How To Use Cron to Automate Tasks on CentOS 8

A previous version of this tutorial was written by Shaun Lewis.

Introduction

Cron is a time-based job scheduling daemon found in Unix-like operating systems, including Linux distributions. Cron runs in the background and tasks scheduled with cron, referred to as “cron jobs,” are executed automatically, making cron useful for automating maintenance-related tasks.

This guide provides an overview of how to schedule tasks using cron’s special syntax. It also goes over a few shortcuts one can use to make job schedules easier to write and understand.

Prerequisites

To complete this guide, you’ll need access to a computer running CentOS 8. This could be your local machine, a virtual machine, or a virtual private server.

Regardless of what kind of computer you use to follow this guide, it should have a non-root user with administrative privileges configured. To set this up, follow our Initial Server Setup guide for CentOS 8.

Installing Cron

Before installing cron on a CentOS machine, update the computer’s local package index:

Then install the cron daemon with the following command:

This will install cron on your system, but you’ll need to start the daemon manually. You’ll also need to make sure it’s set to run whenever the server boots. You can perform both of these actions with the systemctl command.

To start the cron daemon, run the following command:

To set cron to run whenever the server starts up, type:

Following that, cron will be installed on your system and ready for you to start scheduling jobs.

Understanding How Cron Works

To schedule a job, you just need to open up your crontab for editing and add a task written in the form of a cron expression. The syntax for cron expressions can be broken down into two elements: the schedule and the command to run.

The command can be virtually any command you would normally run on the command line. The schedule component of the syntax is broken down into 5 different fields, which are written in the following order:

Together, tasks scheduled in a crontab are structured like this:

Here’s a functional example of a cron expression. This expression runs the command curl http://www.google.com every Tuesday at 5:30 PM:

There are also a few special characters you can include in the schedule component of a cron expression to make scheduling easier:

Here are some more examples of how to use cron’s scheduling component:

If you find any of this confusing or if you’d like help writing schedules for your own cron tasks, Cronitor provides a handy cron schedule expression editor named “Crontab Guru” which you can use to check whether your cron schedules are valid.

Managing Crontabs

Once you’ve settled on a schedule and you know the job you want to run, you’ll need to put it somewhere your daemon will be able to read it.

You can edit your crontab with the following command:

This will open up your crontab in your user profile’s default text editor.

If you’d like to use a more approachable text editor as your default crontab editor, you could install and configure nano as such.

To do so, install nano with dnf :

At the bottom of the file, add the following line:

Please note that, on Linux systems, there is another crontab stored under the /etc/ directory. This is a system-wide crontab that has an additional field for which user profile each cron job should be run under. This tutorial focuses on user-specific crontabs, but if you wanted to edit the system-wide crontab, you could do so with the following command:

If you’d like to view the contents of your crontab, but not edit it, you can use the following command:

You can erase your crontab with the following command:

Warning: The following command will not ask you to confirm that you want to erase your crontab. Only run it if you are certain that you want to erase it.

When prompted, you must enter y to delete the crontab or n to cancel the deletion.

Managing Cron Job Output

Because cron jobs are executed in the background, it isn’t always apparent that they’ve run successfully. Now that you know how to use the crontab command and how to schedule a cron job, you can start experimenting with some different ways of redirecting the output of cron jobs to help you track that they’ve been executed successfully.

If you have a mail transfer agent — such as Sendmail — installed and properly configured on your server, you can send the output of cron tasks to the email address associated with your Linux user profile. You can also manually specify an email address by providing a MAILTO setting at the top of the crontab.

For example, you could add the following lines to a crontab. These include a MAILTO statement followed by an example email address, a SHELL directive that indicates the shell to run ( bash in this example), a HOME directive pointing to the path in which to search for the cron binary, and a single cron task:

This particular job will return “Run this command every minute,” and that output will get emailed every minute to the email address specified after the MAILTO directive.

You can also redirect a cron task’s output into a log file or into an empty location to prevent getting an email with the output.

To append a scheduled command’s output to a log file, add >> to the end of the command followed by the name and location of a log file of your choosing, like this:

Let’s say you want to use cron to run a script but keep it running in the background. To do so, you could redirect the script’s output to an empty location, like /dev/null which immediately deletes any data written to it. For example, the following cron job executes a PHP script and runs it in the background:

Restricting Access

You can manage which users are allowed to use the crontab command with the cron.allow and cron.deny files, both of which are stored in the /etc/ directory. If the cron.deny file exists, any user listed in it will be barred from editing their crontab. If cron.allow exists, only users listed in it will be able to edit their crontabs. If both files exist and the same user is listed in each, the cron.allow file will override cron.deny and the user will be able to edit their crontab.

For example, to deny access to all users and then give access to the user ishmael, you could use the following command sequence:

First, we lock out all users by appending ALL to the cron.deny file. Then, by appending the username to the cron.allow file, we give the ishmael user profile access to execute cron jobs.

Note that if a user has sudo privileges, they can edit another user’s crontab with the following command:

By default, most cron daemons will assume all users have access to cron unless either cron.allow or cron.deny exists.

Special Syntax

There are also several shorthand commands you can use in your crontab file to help streamline job scheduling. They are essentially shortcuts for the equivalent numeric schedule specified:

Note: Not all cron daemons can parse this syntax (particularly older versions), so double-check it works before you rely on it.

Additionally, the @reboot shorthand will run whatever command follows it any time the server starts up:

Using these shortcuts whenever possible can help make it easier to interpret the schedule of tasks in your crontab.

Conclusion

Cron is a flexible and powerful utility that can reduce the burden of many tasks associated with system administration. When combined with shell scripts, you can automate tasks that are normally tedious or complicated.

Want to learn more? Join the DigitalOcean Community!

Join our DigitalOcean community of over a million developers for free! Get help and share knowledge in our Questions & Answers section, find tutorials and tools that will help you grow as a developer and scale your project or business, and subscribe to topics of interest.

How to Use Cron to Automate Linux Jobs on Ubuntu 20.04

#What is Cron?

Cron is a Linux job scheduler that is used to setup tasks to run periodically at a fixed date or interval. Cron jobs are specific commands or shell scripts that users define in the crontab files. These files are then monitored by the Cron daemon and jobs are executed on a pre-set schedule.

#Prerequisites

To follow this guide, you should have:

#Install Cron

Most often Cron is installed to your Ubuntu machine by default. In case it is not there, you may install it yourself.

Update your system’s local package list:

sudo apt update

And install the newest version of cron. The following command also updates Cron to the latest version, if you already have it installed:

sudo apt install cron

Congrats! You now have the latest version of Cron installed on your machine.

#Understand How Cron Works

Cron jobs are commands or shell scripts that are referenced in crontab files. These files are loaded into memory and monitored for pre-set actions that need to be taken. Cron wakes up every minute to examine all stored crontabs and see if any command needs to be executed in the current minute.

Additionally, Cron monitors the modification time of each crontab file on the system. If any crontab has been changed, it is automatically reloaded into memory. This way Cron doesn’t need to be restarted when a crontab modification is made.

💡 Pro Tip: Cron assumes that your system is running continuously 24/7, so it is perfectly suited for servers that must be online all the time. However, cron cannot execute tasks that were scheduled for a time when your system was offline. As this may be an issue for desktop computers, use anacron instead to schedule jobs at the specified intervals as closely as machine uptime permits.

#Setup Your First Cron Job

If you are creating crontab for the first time, you will be asked to select your default text editor. Select your preferred editor [1 – 4] and press ENTER to open a new crontab with your selected text editor. The newly created crontab is populated with some useful comments:

Let’s now add a new Cron job to the bottom of this file:

Save the file and exit. Wait a few minutes and check the greetings.txt file that should have been created in your home directory and populated with relevant data:

As you can see, every minute Cron executes the given task: current time is stuffed into the “Hello World […]” string and appended to the bottom of the file.

#Understand Cron Job Syntax

Every Cron task is written in a Cron expression that consists of two parts: the time schedule and the command to be executed. While the command can be virtually any command that you would normally execute in your command-line environment, writing a proper time schedule requires some practice.

The Cron task syntax consists of 6 arguments separated by spaces. First 5 arguments describe the execution time, while the last argument is a command or a full path to a shell script that is going to be executed by the default shell:

[minute] [hour] [day of month] [month] [day of week] [command]

Commands are executed by Cron when the minute, hour and month fields match the current time, and when at least one of the day fields – either day of month, or day of week – match the current time. The allowed values are these:

There are also some special characters that you can use to further specify the execution time:

You may play with execution time targeting rules by using the crontab.guru website which is a great place to deepen your understanding and double check whether you defined the execution time right.

💡 Pro Tip: the @reboot runs once at the cron daemon startup. It may happen before some other system daemons are started due to the boot order sequence of the machine. This may cause some of the commands not working properly.

#Manage Crontab Configuration Files

Crontab, also known as the Cron table, is a list of environment settings and Cron commands that are stored in a file and used by the cron daemon to execute tasks on a scheduled basis. There are different types of crontab files available, so let’s review them one by one.

#Manage User-owned Crontab Files

Users have their own crontab files that are stored in the spool area and named after the user’s account. Each crontab is executed as the user who owns the crontab. You can check for user-owned crontab files by listing all files in the spool directory:

Crontab configuration files of the individual users should not be edited directly, but rather by using the crontab command. The crontab program verifies and installs the crontab file itself without a need for root privileges.

As you can see, there is a single active Cron task that we have added before.

If you would like to remove your crontab file to terminate all your scheduled tasks, use the following command:

#Manage System-wide Crontab Files

System-wide crontab files are created upon cron installation and mainly used by system services. Packages like dpkg, sysstat and many others depend on cron and use it to schedule specific tasks. In a system’s crontab there is a user field that is used to execute given tasks.

System crontabs must be owned by root and cannot be edited by any other user. There is no crontab command to edit these files, so they can be accessed directly by the system administrator. Let’s now access the main system crontab:

Any script in above mentioned directories must pass the run-parts verification. A script must be executable, owned by root, and not be writable by group or others. Let’s now create a simple bash script that is going to log Bitcoin prices every hour:

Our script queries a Coinbase API, gets Bitcoin price information in JSON, parses it with the jq program to cherry-pick the price and logs it along with the current datetime to bitcoin_prices.txt file in the /root home directory.

A script you put into /etc/cron.daily/ directory can be any script you like to be executed on an hourly basis. Just don’t forget to write a path to your preferred shell at the top ( #!/usr/bin/bash ) and make your script executable:

chmod u+x /etc/cron.daily/get_bitcoin_price

You may double check your script to make sure it is executable, owned by root, and are not writable for group and others:

It seems our script is well-configured and ready to be executed by Cron on an hourly basis.

There is also a /etc/cron.d/ directory in Debian-based systems. Cron treats all files in this directory in the same way as the main /etc/crontab file, except that crontab files put into /etc/cron.d/ do not load environment variables. It is only recommended to create separate crontab files in the /etc/cron.d/ directory if you need that extra isolation.

#Manage Cron Output

The output of cron jobs – both STDOUT and STDERR – is automatically sent to the crontab owner’s local mailbox by default. Each user’s mailbox is a standard text file that is stored in the /var/mail/ directory. You may access it directly or through the mail command, if mailutils package is installed.

A user’s local mailbox is different than an email sent over the Internet. If you want to send an email outside of your server, you may do so by specifying the MAILTO directive accordingly:

Of course, if you are sending an email through the Internet network, you must have some type of an SMTP server – Sendmail, Postfix, etc – running on the same host or on your LAN.

#Manage Cron Logs

Cron logs are stored in the /var/log/syslog global logging file by default. If you want to see your Cron activity, filter the syslog file to find CRON service activity:

grep CRON /var/log/syslog

Crontab file activity is also logged. If you want to see it, just filter the syslog file accordingly:

grep crontab /var/log/syslog

It is not very convenient to filter the global log file every time. A better practice is to configure rsyslog utility to copy cron logs in a separate file. To do so edit the following file:

You need to uncomment the following line:

Save the file and restart rsyslog service for the configuration to come into effect:

systemctl restart rsyslog

After a while you should see a new cron.log file created in the /var/log/ directory with your Cron activity logs inside:

If you haven’t changed syslog configuration, every log entry follows a standard pattern:

[timestamp] [hostname] [app_name] [log_message]

You can see the log rows follow this pattern, for instance:

Let’s dissect these fields:

💡 Pro tip: You are not going to see logging information about scripts that have been executed in the /etc/cron./ directories, unless those scripts explicitly direct the output to the cron.log file.

#Monitor Cron Jobs With Cronitor

It may be a hassle to go back and forth through your Cron logs, especially if you have hundreds of jobs running on your system. Luckily, there are Cron job monitoring tools available in the market that help you monitor your cron jobs and get insights in real time.

One such tool is Cronitor that captures the status, metrics, and output of every Cron job. With tools like Cronitor you may easily name and organize each job, as well as ensure that the right people are alerted if something happens.

Monitoring 5 Cron jobs with Cronitor is free of charge and it is easy to get started. After you install Cronitor CLI and configure your API key, run the following command to scan your system crontabs for all active Cron jobs:

You will be prompted to name your Cron jobs and, after you are done, Cronitor will immediately start monitoring them. You can check the status of your Cron jobs and configure alerts on your Cronitor dashboard:

#Conclusion

Cron is a powerful tool that is often used by system administrators to automate otherwise tedious tasks. After completing this guide, you now have a well-rounded understanding of how to use Cron to schedule tasks on your Linux systems. For any further information, feel free to check the official Cron documentation page.

Mantas Levinas

Helping engineers learn 💡 about new technologies and ingenious IT automation use cases to build better systems 💻

Join Cherry Servers Community

Get monthly practical guides about building more secure, efficient and easier to scale systems on an open cloud ecosystem.