If you’ve spent any time working on a *nix based operating system, if you’ve heard the term cron job then you probably have heard it a lot, but chron jobs still are often a source of confusion and pain for many software engineers.

In this article we’ll delve a bit deeper into the basics of cron, covering how to write a cron job, and how to manage your cron jobs using the crontab command. Finally we’ll review some common mistakes developers make when configuring cron jobs.

What Is a Cron Job?

A Cron Job is a Linux program which executes a task, which could be a shell script or compiled application, only when requested by its master (Crontab) – at a time of our choosing. If you’ve got a task you want to run at a fixed schedule, or to automate a routine, such as downloading a file or sending an email, you can use cron.

A cron job is essentially an entry in the table (by the ingenious name of cron table or crontab, for short). The schedule and a command to run are part of this entry. The cron daemon (crond) finds jobs in the crontab that such a crontab should schedule to run, and at what time.

Note: All the examples below in this article will run on Ubuntu. Linux OSs vary and might use different package managers, but you just change that particular command but all other commands will work the same.

How Do Cron Jobs Work?

Most standard installations of cron consists of two commands:

• cron or crond, which is the daemon that runs the scheduling utility
• crontab, which is the command that allows you to edit the cron entries for your jobs

A program launched in the background but non interactive; this is when you talk about a daemon from a Linux point of view. It simply does not allow for user input and doesn’t display output to the user. A daemon historically is a word used in Unix/Linux context and does not have one universal meaning for the word across different operating systems.

This daemon will be run by the root user. You can run the following command to see if cron is running:

$ ps aux | grep cron

Copy

You should see an output like this:

root     	617  0.0  0.0   9420  2800 ?    	Ss   17:00   0:00 /usr/sbin/cron -f

Copy

If you received no output from the command at all, either cron isn’t running or is not installed.

On Ubuntu you can quickly install cron by running the following command:

$ sudo apt update && sudo apt install cron

Copy

If you’re using something other than Ubuntu, you’ll need to run the equivalent command for your package manager.

Once cron is installed, remember to make sure it is enabled and running using the systemctl command provided by systemd:

$ sudo systemctl enable cron

Copy

Cron should now be running, and you should be able to see it if you again run the ps command shown above.

Managing Crontab Entries

Once cron is running, it checks for crontab entries in the following files every minute:

• /etc/crontab
• /var/spool/cron/crontabs/$USER (where $USER is the currently logged-in user)

The first file, /etc/crontab, is a system-generated file containing shortcut commands designed to check for cron table entries in the following directories: /etc/cron.hourly, /etc/cron.daily, /etc/cron.weekly, and /etc/cron.monthly.

You can achieve this by using the crontab command. From the terminal, enter edit mode for your user’s crontab using the following command:

$ crontab -e

Copy

The first time you run this command, the OS should ask you what editor you would like to use with a little menu like this:

no crontab for user - using an empty one

Select an editor.  To change later, run 'select-editor'.
  1. /bin/nano    	<---- easiest
  2. /usr/bin/vim.basic
  3. /usr/bin/vim.tiny
  4. /bin/ed

Choose 1-4 [1]:

Copy

Pick an editor. For the most part, nano is an easy to use editor, so you don’t mind much if you’ve never used an editor on your Linux system.

Once you’ve made your selection, the editor you’ve chosen will come up with the default crontab for your user

Common Cron Job Errors

You may have thought that cron up until now is a powerful thing and nothing wrong would happen while we use it. Right? Wrong.

So any experienced system administrator who’s ever set up a cron job for any amount of time will tell you that cron jobs fail all the time, for a zillion reasons.

Here’s some overview of some of the problems you can come across while configuring cron jobs.

Scheduling Errors

Especially if you haven’t worked with cron before, it’s not too hard to get a cron syntax wrong. Possibly you’ve changed around the minutes and the hours part of the syntax. If you are faced with the same issue you can always check with crontab.guru website that your syntax is correct.

Environment Variables

The second most frequent occurrence is when your shell script seems to work from the command line when you’re running it but it doesn’t seem to work from the cron entry. This is definitely the reason if your script invoke any environment variables. Cron doesn’t load variables from things like .bashrc or bash_profile, even if you’ve defined such common variable as $USER, it doesn’t exist when cron will be running your job entry. If your variable values are not hard coded already, you would need to do it either manually yourself, by loading values from files, such as .bashrc, for example.

Script Executable Permissions

By default, when you create a shell script, it does not have execute permissions:

$ touch shell_script.sh
$ ls -als *sh

Copy

Output:

0 -rw-rw-r-- 1 user users 0 May 21 13:26 shell_script.sh

Copy

The file is missing execute permissions. Give the file executable rights by running the following command:

$ chmod +x shell_script.sh
$ ls -als *sh

Copy

Now the output looks like this:

0 -rwxrwxr-x 1 user users 0 May 21 13:26 shell_script.sh

Copy

This should fix the missing execute permission that cron needs to be able to run the script.