Automate your Linux system tasks with cron

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. 

Using cron

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 -e (edit).

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 file:

$ 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 vi or vim.

Note: If you don’t know how to use vi or 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 crontab entries.

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 crontab:

2 13 * * * /usr/bin/mail [email protected] < ~/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 crontab. The cron daemon checks for the existence of entries in the /var/spool/cron directory automatically. For example, my crontab is /var/spool/cron/khess and contains the two entries above.

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

More examples

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 crontab:

$ 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

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

Wrapping up

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