In the UNIX or Linux environment, it is possible to
asynchronously execute tasks at any desired time of the day, a
feature made possible by the cron clock daemon. In
the following text we will present some general information on how
to use cron and its companion at, as well as some
tips on avoiding problems. Although this discussion is geared
toward the SCO OpenServer implementation of cron, the
basics are applicable to all modern UNIX implementations.
Succinctly stated, cron's role is to spawn jobs in
accordance with the passage of time. cron itself is
normally started at boot time when the system switches to multiuser
operation and once started, never stops unless it is manually
killed or the system is halted. cron is slaved to
the system clock and awakens at one minute intervals to start
scheduled jobs (which are referred to as cron jobs).
When the time arrives to start a job, cron spawns a
shell in which to run the job, thus allowing the job to execute
independently of cron itself. A cron job
executes with the identity and privileges assigned to the system
user who scheduled the job. As a general rule, cron
jobs are arranged to automatically die when they have finished
their work. However, this is not an absolute requirement.
In order to know what is scheduled to run, cron reads
text files called cron tables, which authorized users may
generate and maintain. cron table maintenance is
accomplished with the crontab command. Of the
various crontab invocations, crontab -e and
crontab -l are most often used, the former to create or
edit a cron table and the latter to display it. On
most systems, crontab -e will automatically start the
vi text editor and if a cron table already
exists, load it into vi. Upon saving and exiting
from vi, the new or revised file will be submitted to
cron, overwriting the existing cron table.
Like other UNIX files, each cron table is owned by the
user who created it, and excepting root, can only be
edited or viewed by its owner. root can edit any
user's cron table with the invocation crontab -u
<user> -e or display any table with crontab -u
<user> -l, where <user> is a UNIX
username. A user may remove his or her cron table
with the command crontab -r. root is
allowed to remove anyone's cron table.
CAUTION: The crontab -r command
DOES NOT confirm your intention. Once deleted, the
cron table is gone forever. Unless there is a
compelling reason to do so, avoid editing root's
A cron table file is ordinary ASCII text and consists of
one or more lines specifying what is to be executed and when.
A typical cron table line takes the general form:
day mon dow
where min and hour define the time of day (in 24
hour format) at which execution is to commence, day
defines the day of the month on which to start execution,
mon defines the month in which to start execution, and
dow definess the day of the week on which to start
execution. The command field specifies what is to be
executed, using Bourne shell syntax, and may include
arguments. It is highly recommended you use a fully qualified
filename for command, as cron normally limits its search
to /bin and /usr/bin. If command
cannot be found, cron will complain by sending local mail
to the owner of the cron table.
Scheduling is quite flexible. Permissible values for the
date and time fields are as follows:
min 0-59 hour 0-23 day 1-31 mon 1-12 dow 0-6 (Sunday =
Scheduling values are cumulative: if you specify both a
day and dow value, cron will attempt to
obey both parameters. In addition to the above values,
cron understands an asterisk (*) to mean all
legal values for the field where it is used, and also understands
numeric ranges. For example, if the dow parameter is
0,3,6 it tells cron to execute the job on Sunday,
Wednesday and Saturday. If the dow parameter is
1-5 it means execute the job Monday through Friday
inclusive. You could also specify 0,15,30,45 for the
min field and asterisk everything else, which would cause
the job to run at 15 minute intervals, starting with every hour on
the hour. If all fields are asterisks, cron will
attempt to run the job at one minute intervals.
Any text following an octothorpe (#) is treated as a
comment and ignored by cron. Reasonably terse
comments are recommended. All parameters must be separated by
at least one space or tab (tabbed columns are suggested for
This entry will cause cron to start
/usr/local/bin/archive_files at five minutes after
midnight on the first day of January of each year. The
asterisk in the dow field indicates to cron that
any day of the week is acceptable. However, since an explicit
month and day have been specified, the day of the week is
effectively ignored. archive_files would be a
user-written shell script or program that would perform whatever
processing that was required. See the crontabman page for more information. Incidentally, leading
zeros in the numeric fields are permitted and generally help to
improve the readability of the table when fields are tab-delimited.
Theoretically, it is possible to execute any UNIX script or
program with an entry in a cron table. However, the
execution environment into which a cron job is spawned is
very limited in scope, being determined by the parameters in the
/etc/default/cron file, as well as the rights of the user
owning the cron job. In most cases, the default
shell will be the Bourne shell (or bash on Linux systems)
and the default path will be limited to /bin,
/usr/bin and on OpenServer, /usr/lbin.
Therefore, the first thing your cron job script should do
is set up a suitable environment, such as augmenting the path
definition, defining a subdirectory for temporary file storage, and
As stated before, a cron job inherits the identity and
access privileges of the owner of the cron table from
which the job was spawned. It is essential you understand
this characteristic of cron, as you may run into trouble
with your program if it is denied access to a directory or file due
to ownership and access rights. Similarly, be sure your
cron job correctly sets the umask value so that
any files that are created inherit the correct permissions.
As always, information about how your system implements
cron can be gleaned from local man pages.
It is important to consider the effects of daylight savings time on
cron's operation. OpenServer will reschedule any job
that is supposed to run between 2:00 AM and 2:59 AM on the day when
the switch is made from standard to daylight savings time.
This is because immediately following the time change the period
from 2:00 AM to 2:59 AM will cease to exist. Similarly, any
job scheduled to run between 2:00 AM and 2:59 AM on the day the
switch back to standard time is to occur may be run twice, as that
time range will be repeated. The best policy is to not
schedule anything to run between 1:59 AM and 3:00 AM if your locale
observes daylight savings time.
Normally the output of any program is sent to STDOUT
(standard out) and usually winds up on someone's display
screen. For jobs started by cron, STDOUT
will be directed to the local mail subsystem, which means any
output generated by a cron job will be mailed to the user
owning the job. If this is not desirable you should take
steps to redirect your cron job's output to a file.
It is also suggested you redirect STDERR (standard error)
to a file so as to be able to analyze any anomalies in your
cron job's execution.
Another possibility is to E-mail your cron job's output
to a remote user by piping the output to the mail
command. For example:
Closely related to cron is the at command.
Like cron, at can run any job at a scheduled
time. However, at will only run the job once, unless
the job reschedules itself. at is invoked from the
command line or from within a shell script. The basic command
where <time> is when to execute the job. The
above invocation will cause at to read STDIN for
a list of commands to be executed at <time>.
Once you have type in a command list and have exited with Ctrl-D,
the job will be submitted.
Alternatively, you could say:
at <time> < FILE
where FILE is a shell script of some sort that has been
prepared from a text editor.
<time> can be in several forms, such as 12 or 24
hour clock time, a date and time, an offset to the current time
(e.g., now + 5 minutes) or similar. Again, see your
local man pages for details.
As with cron, at's execution environment is
limited in scope, and the rights assigned to the at job
will be the same as those belonging to the invoking user. If
your at job cannot get access to something because of
insufficient privileges it will complain via local mail.
Use cron to execute jobs on a regular schedule (e.g., run
an automatic tape backup each work night or generate end-of-month
reports). Use at to run a job once at some time in
the future. Use them both to automate your repetitive tasks!