Raiden's Realm: Linux Tip Guide: Automating Tasks with Cron

Linux Tip Guide: Automating Tasks with Cron (Page 1 of 1)

Written by Steve Lake
Posted on: Sep 13, 2006 at 01:49am
Section: Tutorials
Printer Friendly Version
Legacy URL

At some point in your experience using Linux you will need to automate some tasks. These can be anything from a very important report to something as benign as grabbing your mail. The traditional method to do this is through cron. Everything that cron does is controlled through a simple text file. While the thought of editing a text file can seem simple enough, the format required to make it work can quickly frustrate or intimidate any new user. But it's not meant to. Once you understand how cron works, it's very easy. Let me show you how simple it actually is.

When you first open the cron file you'll see a lot of entries that look something like this:

1 3 * * * root /path/script
The simple way to understand this is by looking at each of its component parts. Each entry in the crontab file is divided into a virtual column and each entry tells crontab something different. The names of each of these columns are as follows in the order they appear: minute, hour, mday (day of the month), month, wday (day of the week), who (aka which user), command (the command to be executed). That might seem confusing, but it's not. One way to look at this is to ask yourself "What do I want to execute, when do I want to execute it and how often?" If you can answer these three questions, you've done most of the hard part of setting up a cron task.

Let's assume that you want to do a backup ever Friday at 8pm and you want to use the script "backup.cgi" to do it. This is how your entry would look in your crontab file.

0 20 * * 5 root /usr/bin/perl /drive2/backup.cgi >> /drive2/log.txt
Yup, that's all you'd have to do. Still confused? Well let's break it down a bit farther. A trick you can use to help you figure out what to put in your entry is to think about it as a sentence. Maybe something like this:

"Execute backup.cgi every Friday at 8:00pm"
Once you have that, you simply begin pulling apart that sentance from right to left to build your entry. Let's start with the first entry. Since cron doesn't understand AM or PM, we'll toss the letters "pm" off the end of that. Now we have just 8:00. Since the first entry we deal with is minutes, we'll take the first two zeros and stop at the colon. Since two zeros are redundant and cron always ignores a leading zero, we'll drop the second zero. Now we have just "0" for our entry. Put that in the first column. This works the same if you want to start your script at 8:23 instead. You'd simply put "23" in your first entry instead. The minutes column uses any number you want from 0 to 59 depending on how many minutes past the hour you want your script or command to execute. Next, we look to the left of the colon and we see an "8". Since we're dealing with 8pm rather than 8am, we'll need to convert this into military time first before we can use it. A simple rule of thumb when converting civilian time to military time is to think of the rule of 12. If the time of day is 1pm or later, take the time and add 12. So 1pm because 13 and 8pm becomes 20. Any numbers of 12 or less remain the same. The hour column uses any number from 0 to 23 with midnight always being specified as "0".

So now we have two of our entries filled in. Looking further left past the word "at" we have the word "Friday". Since our third column is for the day of the month, we can simply put an astrix in there (*) to say that we don't care what day of the month this occurs on. If we did care, we'd put a number in there from 1 to 31 to denote which day of the month we wanted this to run. The next column beyond that is for the month of the year, and since we want this script to run regardless of which month it is, we put an astrix here as well. The next column is for the day of the week. This is where "Friday" would fit in. Cron sees the days of the week starting at "0" for Sunday and going on through the week to Saturday which is "6". We want our script to run on Friday, so we would put a "5" here.

Now we've properly scheduled our backup to run every friday at 8pm. But let's take this a step farther. Assume you instead would like the script to run ever five minutes. To do this you need to use a slightly different format for your entry. The first part of the entry is going to be an astrix. An astrix tells cron that regardless of what time it is, always run the command. This is especially bad if you have an astrix by itself in the minutes column. Doing so will make cron run your task every minute until you change the entry or the current time falls outside any values listed in any of the other columns. If the script is especially demanding on the system, ugly things could happen, so be careful how you edit this column. The next two parts of your entry will be a forward slash and a number. In this case, the number 5. So your final entry would look like this: */5

The same rules apply if you wanted the script to run ever seven or ten minutes. You'd end up with "*/7" or "*/10" respectively. Another way to specify a broader period of time for the script to execute is to use either a dash or a comma with your entry. Let's say for example you need to run your script every day at 2, 4 and 6pm. You'd put your entry together like this: 14,16,18 If you wanted to run your script continuously over a period of time, say between 10am and 4pm, you would do your entry like this: 10-16 Same would apply for each column denoting time.

Here's an example cron entry that would use all five of the standard time formatting methods.

*/5 16-20 3 * 1,3,5 root /usr/bin/perl /drive2/disco.cgi
So looking at this entry, this "cronjob" would run every 5 minutes from 4pm to 8pm on the 3rd of each month, but only if that date fell on either a monday, a wednesday, or a friday.

So as you can see, cron can be a very powerful tool for scheduling a lot of things. Now that you've determined when you want your script to run, you'll need to move onto the next column. If you notice, you'll see the word "root" there. That's actually the user on the system whom cron is supposed to execute this script as. Who the script is executed as is as important as what is executed and when. This is because certain files may need to be updated or accessed that only certain users, such as root, would have access to. As a general rule of thumb, always use the user that has the least possible permissions on the system needed to allow the script to run properly. Using a user with higher permissions may pose a security risk to the system, so always play it cautious.

Now if you've been paying attention up to this point, you'll notice that there are spaces between each column. Any space between any numbers or charecters is automatically treated by cron as an indicator of the end of one column and the beginning of another. So be aware of that when creating your own cron entries. It is usually advised to use a tab when separating your columns. Tabs are treated the same as spaces and they provide you with a much neater, column oriented layout that's easy to read and edit.

Now that we've done our first six columns, the last thing we have to do is the command we want to execute. From this point on to the end of the line, you can have as many spaces as you want without affecting how cron reads the entry. This is because cron uses the rule of 7 (aka 7 columns max) and automatically assumes that this is the last column and therefore anything from this point on to the end of the line is to be treated as one single shell command. Generally if a command can be done from the console successfully, then it can be run from cron. In our example above we used the following entry for the shell command:

/usr/bin/perl /drive2/backup.cgi >> /drive2/log.txt
If you notice, everything in the command is specified with full paths. This is because cron never assumes anything. It doesn't look at your home directory, it doesn't look at what your pre-configured paths are, or any of that. It's like dealing with a small child. You have to tell it exactly what you want and you must be very specific about it. In the case of our example we are using a cgi script written in perl to do our backups. Since this is a perl script it needs the perl interpreter to run. In a normal shell environment, just doing ./backup.cgi would be sufficient to execute the script (assuming you're already in the same directory as the script). This is because a typical command shell will automatically read the first line of the script and use the interpreter specified there to process the rest of the script. Cron doesn't do that. So you would have to specify the full path to perl in order to get the script to run via cron. One other thing you might notice is that I also specified a log file for my script by doing the command ">> /drive2/log.txt" at the end of my line. What this does is log any output that cron would generate from running the script to a text file for later browsing. If you'd rather receive this output as a cron report via email just leave that second command off your command line.

One last thing. If you ever need to deactivate a cron entry, you don't need to actually delete it. To deactivate it, just add a pound sign (#) in front of the line you wish to deactivate, and save the file.

Well, that's it. Running cron is exactly that easy. I hope this general overview of cron helps you. If you have anymore questions about this, please feel free to ask in our forums.

Discuss this! ( comments )

Raiden's Realm Social Bookmarking
If you have any problems with any of these links, please let us know. Thanks.

Average vistor rating: 4.6 out of 5 (5 total votes)