CRON is a Unix/Linux program scheduler. It'll automatically
execute commands on your server according to a schedule you
A few of the many uses for scheduled commands are:
~~ Email WillMaster Possibilities ezine at 12:08 GMT every
~~ Do automatic database updates at night when the server is
~~ Send a robot to select sites for verifying certain links
~~ Send a weekly report to you about how much server space
Almost anything that needs to be done according to a schedule
and that doesn't need direct human supervision can be set up
with Unix/Linux CRON.
Note: Some hosting companies don't give their accounts telnet
or SSH (a secure telnet-like connection) access to the server. A
few, in lieu of such access, provide a control panel to set up
CRON schedules. Others do not provide CRON scheduling at all.
To create a CRON schedule, put a list of commands and their
schedules in a plain text file. This text file is called the
"CRON table." Upload the CRON table to your server. Then telnet
or SSH to your server.
Once at your server, type CRONtab filename replacing
"filename" with the file name of the CRON table you uploaded to
your server. This will register your CRON table with the CRON
If you want to verify that the CRON system has indeed
registered your CRON table, type:
(the letter el, not the number 1). That will display a list
of the current registered CRON schedules.
The CRON Table
The CRON table has six fields. The first five fields are
schedule time fields and the sixth is the command itself:
1. The minute of the hour the command shall execute.
2. The hour the command shall execute.
3. The day of the month the command shall execute.
4. The month the command shall execute.
5. The day of the week the command shall execute.
6. The command.
All six fields are on one line. There is one space between
each field. Only field 6 may contain spaces within itself. Here
is an example of what a schedule might look like:
10 3 1 1 * /usr/bin/perl /www/cgi-bin/script.cgi
Comments in the CRON table, ignored by the server, are lines
beginning with the # symbol.
The Five Schedule Time Fields
The order of the fields might seem backward. Most of us are
used to thinking hour before minute, as in 9:45. Also month
before day, as in June 21. However, the fields are minute before
the hour and day before month, with the day of the week as the
Here are the first five fields and their allowed values:
Day of the Month 1-31
Month 1-12 (also 3-letter month abbr)
Day of the Week 0-7 (also 3-letter day of week abbr)
Each of the above values can also contain ranges, lists, and
step values. If a field contains an asterisk (*), it tells CRON
to accept all allowed values.
Step 15-45/5 (another example: */5)
For explanation, let's assume the above is in the Minute
Range 1-3 is a range of 1 through 3, inclusive, and means 1,
2, or 3 minutes after the hour.
List 3,5,7,9 means 3, 5, 7, or 9 minutes after the hour. Step
15-45/5 means every 5 minutes while the clock is 15 through 45
minutes after the hour, inclusive.
Step */5 means every five minutes while the clock is 0
through 59 minutes after the hour (* meaning all allowed values,
which would be range 0-59 minutes).
For purposes of explaining each field, let's use three
1. A script must run one minute before the end of every year.
2. A script must run at 2:20 every Tuesday morning.
3. A script must run every 15 minutes from 9 in the morning
to 9 in the evening. And it must run every 30 minutes the rest
of the time. (Note, this requires two schedule lines.)
The Minute Field
The minute is the first field. The values examples of range,
list, and step, above, illuminate the versatility built into the
For each of the three hypothetical situations, the minute
field would be:
The Hour Field
The hour is the second field. The allowed values are the same
as the minute field, 0-59.
For each of the three hypothetical situations, the hour field
The Day Of the Month Field
The day of the month is the third field. The allowed values
are 1 through 31.
For each of the three hypothetical situations, the day of
month field would be:
The Month Field
The month is the fourth field. The allowed values are 1
through 12. Instead of digits, 3-letter abbreviations may be
1 2 3 4 5 6 7 8 9 10 11 12
jan feb mar apr may jun jul aug sep oct nov dec
For each of the three hypothetical situations, the month
field would be:
The Day Of the Week Field
The day of the week is the fifth field. The allowed values
are 0 through 7. Digits 1 through 6 represent Monday through
Saturday, respectively. On some systems, 0 represents Sunday and
on others 7 represents Sunday. On a few systems, both 0 and 7
represent Sunday. Your hosting company can tell you which
applies to your server. Or, you may wish to try 0 and see if the
script runs on Sunday. If it doesn't, try 7. Instead of digits,
3-letter abbreviations may be used:
0 1 2 3 4 5 6 7
sun mon tue wed thu fri sat sun
For each of the three hypothetical situations, the day of
week field would be:
The Hypothetical Situations Schedules
For each of the three hypothetical situations, the complete
schedule (with an example sixth field) would be:
1. 59 23 31 12 * /usr/bin/perl /www/cgi-bin/script.cgi
2. 20 2 * * 2 /usr/bin/perl /www/cgi-bin/script.cgi
3a. */15 9-21 * * * /usr/bin/perl /www/cgi-bin/script.cgi
3b. */30 0-8,22-23 * * * /usr/bin/perl /www/cgi-bin/script.cgi
The Sixth Field, The Command
The sixth field is the actual command that will be executed
according to the schedule specified in the first five fields.
The sixth field includes any parameters to be passed to the
When the command is a Perl script, you might or might not
need to specify the location of Perl as part of the command.
Your hosting company can tell you which applies for your server.
Here are a three command examples:
/usr/bin/perl /www/cgi-bin/script.cgi response.txt
The first example is a Perl script without the location of
Perl being specified.
The second example is the same script, but this time the
location of Perl is specified.
The third example includes a parameter. Here, the parameter
is "response.txt," which might be the file name that an
autoresponder is to send, assuming the autoresponder script is
named script.cgi. When a script requires parameters, it's
instructions should clearly indicate what the parameters are and
what they represent.
On-line Documentation for CRON and CRONtab
You can type either or both of the following commands at the
telnet or SSH prompt for the on-line CRON and CRONtab manuals.
(It is assumed that any hosting company with CRON available also
has the manuals on-line.)
Those two on-line manuals provide a lot of technical
A Practice Script
You can use the following script to practice what you have
# Verify above line is correct for your server.
my @date = localtime;
$date += 1900;
$date = substr($date,2);
print W "$date\:$date\:$date on ";
print W "$date\/$date\/$date\n";
# Above is USA style date. For European
# style, reverse digits 4 and 3. close W;
# end of practice script
The script will create a file named "track.txt" and print the
time and date. Every time it runs, it creates a new file. The
script is specifically made for running from the telnet/SSH
prompt or with CRON, not for a browser. (Running this script in
your browser will generate an internal server error. That's
because the script never returns anything to the browser.)
When the script is uploaded, you can test it from the
telnet/SSH prompt. To test, type the command you'll be using
when you create the CRON schedule.
Once the script runs correctly, create the CRON schedule. You
may wish to use */3 or something similar in the minute field
while testing. As you now know, that will launch the script
every three minutes; then the longest you'll wait between tests
is three minutes.
Once the test is over, remove the test script from the CRON
schedule. Launching a script, whether with CRON or through a
browser, does take some server resources.
Using CRON, you can schedule events from simple to
sophisticated timing. It's all specified in the first five
Copyright 2002 Bontrager Connection, LLC
"WillMaster Possibilities" ezine