What is a Crontab?
A cron is a utility that allows tasks to automatically
run in the background of the system at regular intervals by use of the
cron daemon. Crontab (CRON TABle) is a file which contains the schedule
of cron entries to be run and at what times they are to be run. This can
be quite useful. For example, you may have a GEMPAK script that creates
upper air maps for your webssite that you wish to run every 12 hours (after
the data comes in), or you may have a personal temporary directory that
you wish to be cleaned out once a day to keep your quota from being exceeded.
This is where cron scheduling comes in to play. Not all systems allow
for a cron schedule to be setup. You need to see your system administrator
to see if it is available on your system.
How does it work?
A cron schedule is a simple ASCII text file. Each user has their own cron
schedule (on Rossby, this is located in /var/spool/cron/crontabs).
The crontab files are not edited (or created) directly and you do not have access to the file without
invoking it from the crontab command. You may not use
any text editor you wish. You must use the text editor that has been specified
in you system variables (see your system administrator for these). The
text editor vi is usually the default text editor. The editor must be
invoked using the -e switch. To create a cron schedule type:
crontab -e
The text editor vi will open a blank window for the "crontab entries"
to be entered. Each line represents a seperate crontab entry (hereafter
referred to as "cron jobs"). (To add comments place # before
any text.). If you are still not completely familiar with the vi editor
you may want to a Unix book (such as UNIX
In A Nutshell) or visit this site
from the University of Illinois
Each cron job has at least 6 sections. Each section is separated by a
single space, but the final section may have spaces within it. No spaces
are allowed within Sections 1-5, only between them. Sections 1-5
are indicate when and how often you want the task (the sixth position)
to be executed. All time are local times not GMT.
Special Note: If the computer system
running the crontab is down, the crontab will not run as well. When the
system comes back up, the crontab will resume its normal activity, but
will not go back and run the jobs that were missed due to the system
being down.
Here is how positions 1-5 are layed out:
|
1
|
Minute | 0-59 |
|
2
|
Hour | 0-23 (0 = midnight) |
|
3
|
Day | 1-31 |
|
4
|
Month | 1-12 |
|
5
|
Weekday | 0-6 (0 = Sunday) |
An asterisk (*) is used to indicate that every instance (i.e. every hour, every weekday, etc.) of the particular time period will be used.
If you wish to use more than one instance of a particular time periods, then seperate the times by a comma. If you wish for continuous execution, the start and stop items are separated by a dash. For example, if you wanted to run your command at :05 and :35 past the hour, every hour, Monday through Friday, then your time stamp would look like this:
5,35 * * * 1-5
The sixth position indicates which task will be run at the given time(s). For example, if you wanted to remove all of the files in you "temp" directory every morning at 4:45 AM, your command would look:
45 4 * * * rm /home/{username}/temp/*
(Where you insert your username where appropriate.)
Special Note: While system commands are normally located in the same directories with standard settings for almost all machines, it is best to put the full path of the directory to any commands, system or not. For example, it would be better to use /usr/bin/rm instead of just rm (on weather.ou.edu). This also applies to any scripts. If there are not full paths to system commands (or other local commands), then it is possible that the cronjob will error. It is always best to include full path names on all commands.
Only command lines, blank lines and comments may be place in a crontab file. Any other type of text will cause the crontab to not function properly.
Now what?
Once the file is saved, the crontab is running. You do not need to initialize, or run any start-up program. Crontab executes when there is/are a command(s) (not comments or blank space) in the setup file (the one created above). If at any time you wish for command in the crontab file to not run anymore, just delete (or comment out) the line containing the command. If you wish to have no crontab jobs running at all, just remove (or comment out) all of the lines containing commands. (To add comments place # before any text.).
What are some examples?
This is an example of a crontab file that runs GEMPAK scripts for upper air maps at 9AM and 8PM everyday, and surface maps every 20 minutes past the hour. (The slight delay allows for enough time for the data to be ingested before the scripts commence to running).
There are also a couple of examples (as well as online help) of crontab files if you type:
man crontab
at the Unix prompt.
Are there any toggle options to Crontab?
Yes, one has already been introduced. The -e option allows you to edit your cron file (or create a cron file does not exist). There are three toggle options to crontab:
|
-e
|
Edit (or create) a crontab file |
|
-l
|
List the crontab file |
|
-r
|
Remove the crontab file. |
Why do I keep getting an email each time my Cron job runs?
The email is crontab's way of notifing you that it has completed (or not) the job you requested it to run. After everything is running smoothly, you may want to disable this feature, or redirect the output to a log file instaed of an email.
If you wish to diasble the email (and not output to a log file) then, at the end of each of the cron job lines you wish to not be notified on, place the command:
>/dev/null 2>&1
This essential writes the email out to nowhere (a trash bin of sorts), and thus solves the problem. Your final cron job line will look like this:
45 4 * * * rm /home/{username}/temp/* >/dev/null 2>&1
If you wish to diasble the email (and output to a log file) then, at the end of each of the cron job lines you wish to not be notified on, place the command:
> {logfile path and name}
or
>> {logfile path and name}
Special Note: One > means replace the current log with a new one, while (two) >> means append the current output to the end of the current log.
This essential writes the email out to nowhere (a trash bin of sorts), and thus solves the problem. Your final cron job line will look like this:
45 4 * * * rm /home/{username}/temp/* > /home/{username}/cronlogs/clear_temp_dir.txt >/dev/null 2>&1
That's it?
As has been show, there is not really too much to learn in order to use crontab. It is a quite useful tool in automating your recurring tasks. Happy crontabbing!!!