It might surprise the saltiest of system administrators to know that there is no Linux
cron command. The cron daemon (
crond) is a system-managed executable that runs in memory with which users may schedule tasks. The user command to work with the
cron service is
crontab (cron table). The
crontab file is a simple text file that instructs the
cron daemon to perform a task at a certain time or interval. Any user may schedule
cron tasks or jobs on a system. The task runs under the user account from which it was created. In other words, if you create a
cron task, it runs with your user account's permissions. The same is true for any user on the system, including the root user.
You can issue the
man crontab command to see all possible options, but there are generally two that work for most users:
-l (list) and
To see a list of your configured
cron tasks, use:
$ crontab -l no crontab for khess
I have no
cron tasks running yet. To create one, I need to edit my
$ crontab -e
Note: There is no file name or designation of any kind required when creating a
crontab entry. Each user has only one
crontab file and you add all tasks to it.
There is nothing particularly special about the
crontab editor except that, if you don’t have a specific editor defined with either the
VISUAL or the
EDITOR environment variable, then your editor is probably either
Note: If you don’t know how to use
vim, please refer to my article, An introduction to the vi editor.
Press the I key to enter INSERT mode and begin setting up your crontab entry. The
crontab file has a specific syntax to it. See the image below:
Making it work
As you can see from the image, the positioning of your entries has meaning, and the entries are separated by spaces. An asterisk (
*) means every or all, as in every minute or all hours, every day, and so on. In other words, the image currently illustrates a
crontab entry for a script that will run every minute of every day. This practice, while rare, does exist in some instances. However, for most
cron tasks, you will need to be more specific.
Note: Before setting up a
cron task, run your script or command to see if you have any problems with permissions or paths.
It’s a good practice to provide the full path to any executable inside a script. Likewise, you should also provide the full path to executables or scripts in your
For example, if you have a script that needs to create a file from the
dmesg command once a day at 1pm, your entry looks like the following:
0 13 * * * /usr/bin/dmesg > ~/dmesg.txt
And if you want to email this file to yourself, you can add an additional entry into your
2 13 * * * /usr/bin/mail firstname.lastname@example.org < ~/dmesg.txt
Save the file by exiting it as you would exit
vi or your default editor. There is nothing special you have to do to enable this edited
cron daemon checks for the existence of entries in the
/var/spool/cron directory automatically. For example, my
/var/spool/cron/khess and contains the two entries above.
cron daemon runs as root so it can read the directory's contents since only the root user has access to this directory. It would be a serious security violation for other users to access
/var/spool/cron and read the
crontab entries for other users on the system.
For the following examples, assume that you have a script,
backup.sh, that you want to schedule on your system. You've placed all your system scripts in
/etc/scripts, which is a directory that only root has access to.
To schedule the backup script to run every night at 2am, open the root user's
$ sudo crontab -e
then enter the following:
0 2 * * * /etc/scripts/backup.sh
Save and exit the file.
Let's try something a little more advanced. Schedule the backup script to run at 2am every Monday. Now, what does the
crontab entry look like? Refer back to the
crontab syntax image for hints:
0 2 * * 1 /etc/scripts/backup.sh
1 in the fifth column instructs
cron to run this script on Monday.
Rather than have your special backup script run every Monday, run it on the 15th of every month:
0 2 15 * * /etc/scripts/backup.sh
What if the backup script only backs up a single mission-critical directory? You want that directory's contents backed up every 15 minutes. Here's how that would look, which isn't 100% intuitive:
*/15 * * * * /etc/scripts/backup.sh
The traditional method of setting this every 15-minute schedule looks like the following:
0,15,30,45 * * * * /etc/scripts/backup.sh
And similarly, if you want to run the script only Monday through Friday, your entry changes to:
*/15 * * * 1,2,3,4,5 /etc/scripts/backup.sh
As you can see,
cron scheduling is easy once you understand the syntax. The only real stumbling blocks you might experience with
cron are pathing, permissions, and timing. You have to think about how long a script requires to execute and produce output before scheduling another process that depends on it. Referring back to the
dmesg script, you can see that you need to know how long the
dmesg command requires to finish processing and writing to the
dmesg.txt file before scheduling the next command, which is to email the
dmesg.txt file to yourself.
Typically, the way system administrators and other users automate processes on a Linux system is to create scripts that perform functions such as creating files, moving files, emailing information, performing backups, reporting on backups, etc. When you schedule those same scripts in
cron, you've created true automation on your system. There are very few repetitive tasks that cannot be automated using
cron and scripts. If you experience problems with automating tasks that require passwords or interactive sessions, use
expect scripts to automate those. If you don't know
expect, watch Enable Sysadmin for future posts on the topic.
There are other ways to automate things in Linux in addition to
cron. For example, the
at command can be used to run a job at a specific time. You can also set tasks to run at specific times by using systemd, though the systemd timers system.
[Want to try out Red Hat Enterprise Linux? Download it now for free.]