This tutorial is a complete guide on understanding cron on Linux as well as the role of the crontab file.
As a system administrator, it is very likely that you spend a lot of time doing recurring tasks on your system.
Luckily for you, there is a way to automate tasks on Linux systems : cron jobs.
Initially built in 1975 by the AT&T Bell Laboratories, cron has evolved to become a reference on Linux when it comes to scheduling and executing tasks at fixed dates or periods.
In today’s tutorial, we are going to take a look at the cron daemon, cron jobs and the crontab command on Linux.
We will also point out the difference between user-defined cron jobs and system-defined cron jobs.
What are Cron and Cron Jobs?
Cron is a system daemon run on any Linux system that is responsible for detecting cron jobs and executing them at given intervals.
Cron runs every minute and it will inspect a set of pre-defined directories on your filesystem to see if jobs need to be run.
On the other hand, cron jobs are tasks defined to run at given intervals or periods, usually shell scripts or simple bash commands.
Cron jobs are usually used in order to log certain events to your Syslog utilities, or to schedule backup operations on your host (like database backups or filesystem backups).
For a Linux OS running systemd as a service manager, you can inspect the cron service by running the following command
$ sudo systemctl status cron.service
Note : you need sudo privileges to inspect system services with systemd
What is the Cron Job Syntax?
The most important to know about cron is probably the cron job syntax.
In order to define a cron job, you are going to define :
- Periodicity: meaning when your job is going to be executed over time. You can define it to run every first day of the month, every 5 minutes or on a very specific day of the year. Examples will be given later on in the article;
- Command: literally the command to be executed by the cron utility, it can be a backup command or whatever command that you would normally run in a shell;
- User: this is reserved for system defined cron jobs where you want to specify the user that should the cron command. For user defined cron jobs, you don’t have to specify a user, and your system will run them as root by default.
As you probably noticed, the periodicity column is made of 5 columns.
Every single column can either be set to *, meaning that the command will be executed for every single value of the interval specified, or to a particular value, for example the 6th month of the year.
If you want to execute a command for every minute, of every hour, of every day of the month, of every month, you would right the following command
* * * * * logger "This is a command executed every minute"
If you want to execute a command every 30 minute, you would write
*/30 * * * * logger "This is executed every 30 minutes"
On the other hand, if you want to execute a command on the first day of the month at midnight, you would write
0 0 1 * * logger "This is executed on the first day of the month, at midnight"
When defining those cron jobs, I didn’t have to specify the user executing them.
This is because there is a difference between user defined cron jobs and system defined cron jobs.
User Defined Cron Jobs
User defined cron jobs are cron jobs defined by a given user on the host. It doesn’t mean that it is not able to execute commands affecting the entire system, but its tasks are isolated on given folders on the host.
Every user is able to have its own set of cron jobs on a Linux host.
Listing user defined cron jobs
When connected to a specific user, run this command to see the cron jobs owned by the user
$ crontab -l
If you own cron jobs, they will immediately be displayed to the standard output.
By default, user defined cron jobs are stored in the /var/spool/cron/crontabs directory but you will need to be root to explore it.
Adding user defined cron jobs
In order to edit the cron jobs related to the user you are connected to, run the following command
$ crontab -e
By default, your host will open your default editor and you will be able to able your cron jobs on the system.
Add a new line to the end of the file with the following line for example
* * * * * logger "This is a log command from devconnected"
Logger is a command that allows users to write custom messages to logs. If you need a complete guide on logging and Syslog, we have a complete write-up on it.
You don’t have to specify a user as the system is already aware of the user defining this command.
Moreover, the command will be executed as the current user by default.
You don’t have to restart any services, your job will be taken into account on the next occurrence.
Given the example we specified earlier, inspect your logs to see your cron job executed
$ sudo journalctl -xfn
As you can see, the cron service inspected user specific directories on the host (in /var/spool/cron/crontabs), it opened a session as my current user, executed the command and closed the session.
You learnt how you can define user defined cron jobs on your host.
Removing user defined cron jobs
In order to remove user defined cron jobs, use the following command
$ crontab -r
$ crontab -ri
Crontab will be deleted for your current user (it won’t delete system defined cron jobs).
Run a cron job listing to check that all cron jobs have been deleted
System defined cron jobs
System defined cron jobs are jobs defined in shared directories on the filesystem.
It means that, given that you have sudo privileges on the host, you will be able to define cron jobs that may be modified by other administrators on your system.
Directories related to system defined cron jobs are located in the etc directory and can be seen by running
$ ls -l | grep cron
As you can see, this folder contains a lot of different folders and files :
- anacrontab: a file used by the anacron service on Linux, which will be explained in one of the next sections.
- cron.d: a directory containing a list of cron jobs to be read by the cron service. The files in cron.d are written given the cron syntax we saw before;
- cron.daily: a directory containing a list of scripts to be executed by the system every day. Files are different from the files contained in the cron.d directory because they are actual bash scripts and not cron jobs written with cron syntax;
- cron.hourly, cron.monthly, cron.weekly are self-explanatory, they contain scripts executed every hour, every month and every week of the year;
- crontab: a cron file written with cron syntax that instructs the cron service to run jobs located in the daily, hourly, monthly and weekly folders. It can also define custom jobs similarly to user-defined cron jobs, except that you have to specify the user that should run the command.
Listing system defined cron jobs
As you probably understood, cron jobs defined in global configuration folders are spread over multiple folders.
Moreover, multiple cron files can be defined on those folders.
However, using the command line, there are efficient way to concatenate all the files in a given directory.
To list all cron jobs defined in cron.d, run the following command
$ cat /etc/cron.d/*
Similarly, to list cron jobs defined in the crontab file, run the following command
$ cat /etc/crontab
Similarly, you can inspect all the scripts that are going to be executed on a daily basis
ls -l /etc/cron.daily/
Adding system defined cron jobs
As you probably understood, there are multiple ways to add system defined cron jobs.
You can create a cron file in the cron.d, and the file will be inspected every minute for changes.
You can also add your cron job directly to the crontab file. If you want to execute a task every minute or every hour, it is recommended to add your script directly to the corresponding cron directories.
The only difference with user defined cron jobs is that you will have to specify a user that will run the cron command.
For example, create a new file in the cron.d directory and add the following content to it (you will obviously need sudo privileges for the commands to run)
$ sudo nano /etc/cron.d/custom-cron
*/1 * * * * root logger 'This is a cron from cron.d'
Again, no need for you to restart any services, the cron service will inspect your file on the next iteration.
To see your cron job in action, run the following command
$ sudo journalctl -xfn 100 | grep logger
This is what you should see on your screen
As you can see your job is now executed every minute by the root user on your host.
Now that you have a complete idea of what user defined cron jobs and system defined cron jobs are, let’s see the complete cron lifecycle on a Linux host.
Cron Complete Cycle on Linux
Without further ado, here is a the complete cron cycle on Linux.
This is what you cron service does every minute, as well as all the directories inspected.
Cron will inspect the user defined cron jobs and execute them if needed.
It will also inspect the crontab file where several default cron jobs are defined by default.
Those default cron jobs are scripts that instructs your host to verify every minute, every hour, every day and every week specific folders and to execute the scripts that are inside them.
Finally, the cron.d directory is inspected. The cron.d may contain custom cron files and it also contains a very important file which is the anacron cron file.
Anacron cron file on Linux
The anacron cron file is a file executed every half an hour between 7:00am and 11pm.
The anacron cron file is responsible for calling the anacron service.
The anacron service is a service that is responsible for running cron jobs in case your computer was not able to run them in the first place.
Suppose that your computer is off but you had a cron job responsible for running update scripts every week.
As a consequence, when turning your computer on, instead of waiting an entire week to run those update scripts, the anacron service will detect that you were not able to launch the update cron before.
Anacron will then proceed to run the cron job for your system to be updated.
By default, the anacron cron file is instructed to verify that the cron.daily, cron.weekly, cron.hourly and cron.monthly directories were correctly called in the past.
If anacron detects that the cron jobs in the cron.monthly folder haven’t run, it will be in charge to run them.
Today, you learnt how cron and crontab work on Linux.
You also had a complete introduction on the cron syntax and how to define your own cron scripts as a user on your host.
Finally, you had a complete cron cycle overview of how things work on your host and of what anacron is.
If you are interested in Linux system administration, we have a complete section about it on our website. Click the image below to check it out.
Until then, have fun, as always.