A.P. Lawrence

UNIX Basics: JOB SCHEDULING

By Steggy
BCS Technology Limited
Email: steggy@bcstechnology.net
Web Site: http://www.bcstechnology.net

More Articles

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.

CRON BASICS

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 cron table.

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:

min    hour    day    mon    dow    command    #comment

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 = 0)

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 clarity).

Here's a cron table entry example:

05 00 01 01 * /usr/local/bin/archive_files #archive files

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 crontab man 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 so forth.

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.

TIME FACTORS

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.

OUTPUT

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:

mycronjob | mail -s "cron job output" you@somewhere.com

ONE TIME CRON

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 is:

at <time>

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.

SUMMARY

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!