Setting Up Cron Jobs

Intro:

Ever wanted to have a specific shell command run at a specific time – or at multiple times – per day, but without having to access your computer/server? If so, utilizing cron by setting up cron jobs is exactly what you’ll need to accomplish that. Cron is a task scheduling utlity that allows you to set up specific jobs within its crontab (cron table) to specify how and when to run a specific command, just like as if you were logged in and running it yourself.

Step 1 – View current list of cron jobs (crontab):

As previously stated, cron jobs are scheduled within what’s called the crontab. However, rather than viewing/editing a specific file to manage the crontab, you’ll want to utilize the crontab program itself to set-up or “install” a new crontab. Let’s start by viewing your current crontab, which, depending on your environment, may or may not contain anything. In this example, we’re using a fresh user who hasn’t had any modifications to their crontab.

test@demo:~$ crontab -l
no crontab for test

 

By using the -l flag, you’ll be able to see the current crontab of the user you’re logged into outputted to stdout (standard output). As stated previously, since this is a new user we don’t have anything currently stored within our crontab.

Step 2 – Make modifications to your crontab:

You should see something like the following when modifying your crontab for the first time:

test@demo:~$ crontab -e
no crontab for test - using an empty one

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

 

Just select whichever editor you’re comfortable with. Though generally I prefer vim, for the sake of simplicity I’m using nano (option 2) for this demonstration, as you’ll just navigate as you would in a normal text editor for the most part. After selecting your editor, you’ll be brought to a blank crontab, which should provide you with a large amount of text, all of which explains the crontab. However, specifically when making changes we’ll be focusing on the last line in the commented out area:

# m h  dom mon dow   command

 

The above is a basic breakdown of the layout of cronjob timing. There are five different options when setting these up, which I’ll list in order as they are shown in line above:

  • Minute (0-59)
  • Hour (0-23)
  • Day of Month (varies on the amount of days in month, however you’ll stick between 1-31)
  • Month (1-12)
  • Day of Week (generally I use 0-6, starting on Sunday, however you’re welcome to start on Monday with 1-7 if you’d like, as Sunday should be covered by both 0 and 7)

Also, when setting the numbers for cron, as you’ll see in the next few examples, you can use the following two characters as well:

  • * (as for most arguments within linux, this specifics “any” in relation to cron job timing. for example, when used in the minutes section * would designate the job to run every minute.)
  • / (this symbol I generally refer to as “every”, as when used with * and a number it designates how often to run the job. example, */2 means every 2. It refers to a relative number, rather than an absolute.)

 

Let’s take a look at a basic cron job example to see how it works:

*/1 * * * * /bin/date >> /home/test/testingcron.txt

 

This command is set up referencing absolute paths of files/programs, which is important if you aren’t using any specific PATH settings, which we’ll explain later. Using absolute paths is generally – in my opinion – best practice when creating cron jobs. To find the absolute path for something like the “date” command, you can run the following:

test@demo:~$ which date
/bin/date

 

But as for the cron itself, let’s break it down:

*/1 * * * *

 

This half of the cron designates when it will run. This specific example will execute every 1st minute of every hour every day. You’ll generally get used to reading the syntax that is used, but if you have problems I’d recommend cronchecker.net to check that your cron is running at the time that you’d like.

/bin/date >> /home/test/testingcron.txt

 

The second half of this cron job simply runs a shell command. In this example, we’re running the date command – which will output the current date/time of the system that you’re on – and appending the output of the command to a file located in our home directory, at /home/test/testingcron.txt. The important part to gather from this part of the example, is that you should be able to copy/paste that entire line into a shell while logged in and have it perform the intended operation. Doing so also can help with troubleshooting problematic cron jobs to ensure the syntax isn’t the issue.

Checking the testingcron.txt file, we can see that it is functioning as intended:

test@demo:~$ cat testingcron.txt
Wed Oct 1 18:07:01 EDT 2014
Wed Oct 1 18:08:01 EDT 2014
Wed Oct 1 18:09:01 EDT 2014
Wed Oct 1 18:10:01 EDT 2014

 

You can also set the specific PATH variable for your crontab to ensure that if a program is called, specific directories are looked in to find that program. Also, you can specify the specific shell to run this under. I’ve provided an example of both below, which would be placed directly above your cron jobs:

PATH=/sbin:/bin:/usr/sbin:/usr/bin:/home/test/
SHELL=/bin/bash

 

Placing these at the top of your crontab – directly below the commented out text (if you left that in) – would allow you to run the following, rather than what we used above:

*/1 * * * * date >> testingcron.txt

 

Once you’ve added a cron job to your crontab, you can save it in nano by exiting, which should install the cronjob.

That’s essentially the entire process for setting up a cronjob. Once this has been completed, it should run as specified. However, if you’re having issues I’d recommend checking the specific log file to ensure that your cron job is running, such as one of the following examples:

/var/log/cron

/var/log/cron.log

/var/log/messages

/var/log/syslog

 

Recommend man page reading:

cron

crontab

Leave a Reply

Your email address will not be published. Required fields are marked *

here's to hoping you're not some complex shell script... *