UNIX Basics: JOB SCHEDULING
Msy 2004 By Steggy
BCS Technology Limited
Email: steggy[email protected]
Web Site: http://www.bcstechnology.net
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
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
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,
defines the month in which to start execution, and
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
. If command
cannot be found, cron
will complain by sending local mail
to the owner of the cron
Scheduling is quite flexible. Permissible values for the
date and time fields are as follows:
dow 0-6 (Sunday =
Scheduling values are cumulative: if you specify both a
will attempt to
obey both parameters. In addition to the above values,
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
it tells cron
to execute the job on Sunday,
Wednesday and Saturday. If the dow
it means execute the job Monday through Friday
inclusive. You could also specify 0,15,30,45
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
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
Here's a cron table entry example:
05 00 01 01 * /usr/local/bin/archive_files #archive
This entry will cause cron
at five minutes after
midnight on the first day of January of each year. The
asterisk in the dow
field indicates to cron
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 crontab
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
'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
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
to a file so as to be able to analyze any anomalies in your
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:
mycronjob | mail -s "cron job output"
ONE TIME CRON
Closely related to cron
is the 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
is when to execute the job. The
above invocation will cause at
to read STDIN
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
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.
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!
If this page was useful to you, please help others find it:
More Articles by Steggy
Have you tried Searching this site?
Unix/Linux/Mac OS X support by phone, email or on-site:
This is a Unix/Linux resource website. It contains technical articles about Unix, Linux and general computing related subjects, opinion, news, help files, how-to's, tutorials and more. We appreciate comments and article submissions.
Publishing your articles here
Jump to Comments
Many of the products and books I review are things I purchased for my own use. Some were given to me specifically for the purpose of reviewing them. I resell or can earn commissions from the sale of some of these items. Links within these pages may be affiliate links that pay me for referring you to them. That's mostly insignificant amounts of money; whenever it is not I have made my relationship plain. I also may own stock in companies mentioned here. If you have any question, please do feel free to contact me.
I am a Kerio reseller. Articles here related to Kerio products reflect my honest opinion, but I do have an obvious interest in selling those products also.
Specific links that take you to pages that allow you to purchase the item I reviewed are very likely to pay me a commission. Many of the books I review were given to me by the publishers specifically for the purpose of writing a review. These gifts and referral fees do not affect my opinions; I often give bad reviews anyway.
We use Google third-party advertising companies to serve ads when you visit our website. These companies may use information (not including your name, address, email address, or telephone number) about your visits to this and other websites in order to provide advertisements about goods and services of interest to you. If you would like more information about this practice and to know your choices about not having this information used by these companies, click here.