Scheduling Tasks - Cron, Crontab, Anacron, At and ....

Some Terminology

What apears a simple little task - run a job on a regular basis can quickly turn into a nightmare at the drop of a keyboard. Let's get some terminology out of the way first to clear the air:

We note Fedora Core (also applies to most Linux distros) specific information with [fc] and FreeBSD information with [bsd]. If not noted specifically it applies to both regimes.

Cron (crond): is the utility that runs continuously and initiates scheduled jobs defined by various parameters. In most systems there are multiple ways to run jobs on a periodic basic and that makes life more, not less, complicated. Jobs scheduled by cron assume the system is running 24 hours per day. If your job was scheduled at a time the system was not running your job does not get run. Sad but true.
Anacron: is the utility that will run scheduled jobs if your system is not running 24 hours per day and these are defined using /etc/anacron. It uses a more modest time specification than cron. Most Linux distros seem to install anacron by default. BSD does not - install from usr/ports/sysutils/anacron. Use man anacron to get more infomation. Not discussed further.
vixie-cron: is the name of an alternate cron (most distros now use vixie-cron) which provides additional functionality such as day names and the special @ syntax.
crontab: is the name of command used to add scheduled jobs.
at: (or batch) are commands that typically have a simpler time specification than cron and may be used to run jobs on a one-off basis according to certain criteria and which are invoked by inspecting /var/at/jobs and /var/at/spool. Use man at or man batch to get more infomation. Not discussed further.

Cron Overview

The cron daemon (crond) runs continuously and schedules jobs using various functions and from files located in a variety of places:

From /etc/crontab - this a special cron file (whose format is not the same as a user crontab). The primary purpose of /etc/crontab is to run system wide jobs and to call [bsd] periodic or [fc] run-parts which will schedule, among others, daily, weekly, monthly and security jobs defined in specific directories. Any job can be added to /etc/crontab (watch the additional user parameter in this file) though in general it is best not to: instead use the most appropriate of the following techniques.
[bsd]If the task is regarded as being part of the system and is to be run on daily, weekly, monthly basis add the script (with the eXecute bit set) to the /etc/periodic/daily or /etc/periodic/weekly or /etc/periodic/monthly or /etc/periodic/security directory. These tasks are run by periodic which is triggered by cron fron /etc/crontab. What is a system task is purely a matter of judgment.

[fc]If the task is to be run on hourly, daily, weekly, monthly basis add the script (with the eXecute bit set) to the /etc/cron.hourly, /etc/cron.daily, /etc/cron.weekly or /etc/cron.monthly directory. These tasks are run by run-parts which is triggered by cron fron /etc/crontab.
[bsd only] If the task is user-level and is to be run on daily, weekly, monthly basis its script can be added (with the eXecute bit set) to the /usr/local/etc/periodic/daily or /usr/local/etc/periodic/weekly or /usr/local/etc/periodic/monthly directories (you may need to create these directories with chown root:wheel, chmod 0755). These tasks are run by periodic which is triggered by cron from /etc/crontab.
[bsd and fc] If the task is to be run by a non-privileged user then add it using the crontab command. When running as a non-privileged user this is normally the only feature available and in many systems only a single crontab is allowed - though since it can point to a script it can run multiple jobs at a time.
[fc only] The crontab file that would have been added via the crontab command may be placed into /etc/cron.d and will be picked up automatically.

system Crontab (/etc/ctontab)

The system crontab is contained in /etc/crontab (more information use 'man 5 crontab'). Edit this file with caution using a standard editor. All changes are picked up automatically and no command is required to alert the system to the changes made. The majority of entries call [bsd] periodic or [fc] run-parts which are utilities that manage regularly scheduled tasks and provide additional capabilities. You can add any entry directly into /etc/crontab (assuming you have the right permissions) but unless it has some unique characteristics, such as the time at which you want to run it, it is probably best advised not to. Jobs that run from /etc/crontab log to (typically) /var/log/cron. The format of /etc/crontab is different to that of a normal crontab in that is has an extra (sixth) entry which defines the user that will run the task as shown below in a default FreeBSD /etc/crontab (the equivalent Linux extract is also shown):


# /etc/crontab - root's crontab for FreeBSD
# sixth field who (who) is not present in a user crontab
#
SHELL=/bin/sh
PATH=/etc:/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/sbin
HOME=/var/log
#
#minute	hour	mday	month	wday	who	command
# (see also cron time format)
*/5	*	*	*	*	root	/usr/libexec/atrun
#
# Save some entropy so that /dev/random can re-seed on boot.
*/11	*	*	*	*	operator /usr/libexec/save-entropy
#
# Rotate log files every hour, if necessary.
0	*	*	*	*	root	newsyslog
#
# Perform daily/weekly/monthly maintenance.
1	3	*	*	*	root	periodic daily
15	4	*	*	6	root	periodic weekly
30	5	1	*	*	root	periodic monthly
#
# Adjust the time zone if the CMOS clock keeps local time, as opposed to
# UTC time.  See adjkerntz(8) for details.
1,31	0-5	*	*	*	root	adjkerntz -a

# EQUIVALENT extract from FC /etc/crontab showing
# run-parts
01 * * * * root run-parts /etc/cron.hourly
02 4 * * * root run-parts /etc/cron.daily
22 4 * * 0 root run-parts /etc/cron.weekly
42 4 1 * * root run-parts /etc/cron.monthly

Periodic

[bsd only]Periodic is run by cron on a daily, weekly and monthly basis from /etc/crontab. It processes files whose location and parameters are defined by /etc/defaults/periodic.conf and /etc/periodic.conf. As always with these files make changes to the /etc/periodic.conf file and leave the /etc/defaults/periodic.conf as the system wide defaults. There is an additional directory /etc/periodic/security which is driven by 450.status-security in the /etc/periodic/daily directory.

The periodic files are looked for, in order, in /etc/periodic/daily, /etc/periodic/weekly, /etc/periodic/monthly (by conventional system tasks) then /usr/local/etc/periodic/daily, /usr/local/etc/periodic/weekly, /usr/local/etc/periodic/monthly (by convention user/application oriented tasks). Files are run in lexical order (ASCII lexical order being: space, $ 0-9 @ A-Z [ a-z ~) which is why, by convention, a number prefix is added to the file name as shown:

# the numeric value has no significance other that 
# a means of determining order
222.firsttask
230.secondtask
231.thirdtask
300.fourthtask

These files will contain scripts to execute the desired task(s) and must have the eXecute bit set for user/group/all - normally 0755. The time specification is implicit in the directory name. The PATH available to any script is the normal system default and explicity does not include /usr/local/bin wherein lies a lot of useful stuff. Either use an explicit path in any utility or set the PATH variable in /etc/crontab appropriately. If you want to use, or add to, the variables from periodic.conf (both /etc and /etc/defaults) add the following lines to your script:

if [ -r /etc/defaults/periodic.conf ]
then
    . /etc/defaults/periodic.conf
    source_periodic_confs
fi

The periodic system sends a single email from each directory, for example all the scripts such from /etc/periodic/weekly will result is a single email to the location defined by the variables daily_output=, weekly_output=, monthly_output= in /etc/defaults/periodic.conf and means that you have do nothing to ensure the output is delivered - other than to ensure your mail alias file maps an appropriate real email address to root (the default destination mailbox name for output).

run-parts

[fc only] Run-parts is much simpler than bsd's periodic. Simply running the script contents of the various directories defined on its command line in /etc/crontab as shown below:

# extract from FC /etc/crontab showing 
# run-parts (see also cron time format)
01 * * * * root run-parts /etc/cron.hourly
02 4 * * * root run-parts /etc/cron.daily
22 4 * * 0 root run-parts /etc/cron.weekly
42 4 1 * * root run-parts /etc/cron.monthly

Jobs are run from the directory in their lexical order (ASCII lexical order being: space, $ 0-9 @ A-Z [ a-z ~). Mailed output destination of each entry is defined by the MAILTO variable. An empty string (MAILTO="") suppresses mail output or you can send the script output to the bit bucket /dev/null. If the thought of all those millions of jobs sending email is too much then you can use a wheeze like this:

# append STDOUT and STDERROR from scripts to a single file
cmd >> /var/log/daily-log.file 2>&1

# add a script with a file name starting 
$ with ~ (tilde) in the directory which will runs last
MAILTO=root
mail -s "your friendly daily cron output" < /var/log/daily-log.file
rm /var/log/daily-log.file
# OR 
cat /var/log/daily-log.file >> /var/log/daily-log-rollup.file
rm /var/log/daily-log.file
# prune /var/log/daily-log-rollup.file periodically

Crontab

Crontab is the method used to schedule tasks for the logged in user (more information use man crontab). To add a task, a file of the following format must be created:

SHELL=/path/to/shell
MAILTO=email-address
# if MAILTO="" (empty) mail is suppressed
HOME=/path/to/somewhere (normally /var/log)
min hour date mo dow task
# for details of time formats see cron time
# task is executed by the defined shell so may be a command or a script

Once the crontab has been created it must be added to the task list by running crontab as shown:

# for the logged in user
crontab /path/to/cron/entry

# to force a particular user
crontab -u user /path/to/cron/entry

# to list crontabs
crontab -l

# to remove crontabs
crontab -r

# to change crontabs either delete and add again or use
crontab -u user -e
# this invokes the standard editor (EDITOR). On completion of the edit
# the task is updated. Just editing the original file will not
# cause crontab to recognize the changes

The cron job runs under the user that issued the crontab command and thus permissions need to be carefully examined.

Allow and Deny cron and crontab access

Cron and crontab access may be allowed and denied selectively based on the presence of two files [fc] /etc/cron.allow and /etc/cron.deny or [bsd] /var/cron/allow and /var/cron/deny. The contents of these files are a single username per line with no leading or trailing white space. If a username appears in an allow file it is allowed and all others are denied. If a username appears in a deny file it is denied and all others are permitted. The keyword ALL may be used in either file. By default neither file exists allowing access to cron and crontab to all users. Examples:

# [fc] /etc/cron.allow or [bsd] /var/cron/allow
# allow these two users - all others denied
bigjim
mypal

# [fc] /etc/cron.deny or [bsd] /var/cron/deny
# deny these two users - all others permitted
bigjim
mypal

Cron Time Specification

The time when a task is run is controlled by 5 parameters as shown below:

# GENERIC format of a crontab
# min hour day mo dow [user] task
# NOTE: the optional [user] value is only present in /etc/crontab
# where 
# min = minute (0  - 59)
# hour = hour (0 - 23)
# day = day of month (1 to 31)
# mo - month (1 - 12) 
# dow = day of week (0 - 7, 0 or 7 = sunday or use name
#                                    e.g. friday)
# task  = thing to be executed by the defined shell and can be
#         a single command line or may point to a script

Complex conditions may be built using variations as shown:

# simple - execute task daily at 2:31pm
# min hour day mo dow task
  31   14   *  *   *  /path/to/script

# multiple times - execute task at 3:10am on 1st and 15th
# min hour day   mo dow task
  10   3  1,15  *   *  /path/to/script
	
# ranges - execute task at 3:10am on 1,2,3 of month
# min hour day   mo dow task
  10   3  1-3    *   *  /path/to/script

# steps - execute task at 3:10am every third day starting from 
# 1st of the month
# min hour day   mo dow task
  10   3   1/3    *   *  /path/to/script
# note: If you start this on, say, the 10th of the month
# it will not start until the beginning of the next month
# to start from now every three days use this form
#  10   3   */3    *   *  /path/to/script

# steps2 - execute task at 3:10am every second sunday
# min hour day   mo dow task
  10   3    *    *   sunday/2  /path/to/script
# the 5 time values can be replaced with the following 
# special, macro, values
# @reboot	   Run once, at startup.
# @yearly	   Run once a year, "0 0 1 1 *".
# @annually	   (same as @yearly)
# @monthly	   Run once a month, "0 0 1 * *".
# @weekly	   Run once a week, "0 0 * * 0".
# @daily	   Run once a day, "0 0 * * *".
# @midnight	   (same as @daily)
# @hourly	   Run once an hour, "0 * * * *".

# run task once per month
@monthly /path/to/script

This handy site provides a nifty little php written tool which takes a time and date string in cron format and tells you the dates and times when it will run.

Some notes about Clocks

The following is a incomplete set of notes about system clocks (having just set up a server on a virtualized server in a timezone which was entirely different to the one that it was required to reflect).

The best way to change the timezone is simply to run the tzsetupcommand (bsd and linux) which copies the relevant binary time zone information to /etc/localtime from /usr/share/zoneinfo.
The tzsetup commands asks whether your system clock is set to UTC or local time and typically advises that if you do not know to select local time. This can lead to bizarre results if you want the timezone info to reflect a non-local timezone. Better to force the system clock to UTC and set the timezone relative to UTC to give consistent results. To force the clock to UTC on boot use the following:
```
# [bsd] /etc/rc.conf
ntpdate_enable="YES"
ntpdate_flags="x.x.x.x [y.y.y.y]"
# where x.x.x.x is the IP address of a suitable NTP server
# y.y.y.y is an optional list of additional NTP servers

# [fc] /etc/ntp/step-tickers
# x.x.x.x may be IP or name of NTP server
x.x.x.x
y.y.y.y
```

Problems, comments, suggestions, corrections (including broken links) or something to add? Please take the time from a busy life to 'mail us' (at top of screen), the webmaster (below) or info-support at zytrax. You will have a warm inner glow for the rest of the day.