![Close [x]](http://dw1.s81c.com/i/c.gif){kind=small}
Open 24/7
Unlike you and me, a computer works tirelessly, applying the same vigor to every task great and small. Moreover, a computer gladly works 24 hours per day, seven days per week, including snow days and federal holidays.
To leverage round-the-clock computing, though, tasks must run at all hours of
the day. You could punctuate your sleep with waking interludes to log in and
run this command or that on dozens of machines, or you can enjoy your 40
winks and turn the work over to the ubiquitous cron,
a daemon (or perennial process) for executing commands on a schedule.
From very often to every so often, cron happily
minds the clock and runs jobs day or night.
Need to monitor an FTP drop-box for incoming data? Use cron
to run a shell script every few minutes. Need to delete scratch files that
accumulate during the day? Slate garbage collection for the middle of the
night. Want to rotate your log files on a regular basis? Set a weekly agenda.
Here, you learn how to configure and maintain cron and
discover its many applications. Specifically, this tutorial looks at Vixie
cron, named after its author, Paul Vixie. Vixie
cron is found in FreeBSD, Apple Mac OS X, most
flavors of Linux, and other UNIX systems. To determine whether your system
runs Vixie cron, type man cron
or man crontab, and look for the attribution for
Paul Vixie at the bottom.
To follow along with this article and to use cron, you
should be familiar with at least one text editor, such as vi or Emacs, and have
some experience with the UNIX command line, shell scripts, and shell
environment variables. Further, if you want to alter the system-wide cron
configuration files, you must have root, or superuser, access.
The cron daemon is a small subsystem of utilities and
configuration files, and a flavor of cron can be
found on nearly every UNIX-like system. Cron's
components include the daemon itself; a collection of system-wide configuration
files; a set of per-user configuration files; a utility to add, alter, and remove user
configuration files; and a simple access control facility. In general, a
cron configuration file or list of cron
jobs is called a crontab, short for cron timetable.
- The daemon,
cron, runs continuously, checking its configuration files for changes once per minute.Cronreads the system-wide and per-user crontabs (described in the next two bullets, respectively), updates its schedule of events accordingly, and executes all commands scheduled to run in the current minute. The daemon also captures the output of each job, if any, and e-mails the result to the job's owner. - System-related jobs can be defined in three places: in /etc/crontab,
in any file in /etc/cron.d, and in the special directories /etc/cron.hourly,
/etc/cron.daily, /etc/cron.weekly, and /etc/cron.monthly:
- The primary system crontab is /etc/crontab. The file has its own unique syntax (described in the next section), and each job defined in it runs according to its own timetable (such as twice an hour or every other day) and as a specific, named user. Use /etc/crontab to schedule miscellaneous administration and maintenance tasks.
- You can also maintain a suite of crontabs in the directory /etc/cron.d. Create a crontab to logically group commands that pertain to a specific subsystem. For example, the package for the PHP version 5 programming language installs a crontab named php5 in /etc/cron.d to periodically purge unused sessions. Files in /etc/cron.d have the same syntax as /etc/crontab, and each job runs per its unique timetable and as a particular user.
- As an alternative, you can simply drop a shell script into one of /etc/cron.hourly, /etc/cron.daily, /etc/cron.weekly, or /etc/cron.monthly to run the script once per hour, once per day, once per week, or once per month, respectively. Scripts placed here run as the superuser.
- The collection of per-user crontabs is commonly found in /var/spool/cron/crontabs.
(Peruse the documentation for your UNIX system for the exact location.
Some systems keep user crontabs in /usr/lib.) However, you cannot directly
edit files in that directory. Instead, you create a crontab and submit the file
with the utility
crontab. Managing your personalcrontabis covered momentarily. - Finally, you can grant or deny a user access to
cronwith the access control lists /etc/cron.allow and /etc/cron.deny, respectively. You might deny access to a user, for example, if his or her jobs were particularly disruptive to normal operation of the system.
As you can see, you need not forego your beauty sleep to keep your machine busy in
the
off-hours. Identify a job, define its schedule, capture the job in an appropriate
crontab, and start counting sheep. But before you doze off, let's look at the special
syntax of cron files.
A crontab is simply a text file, which you can create with any number of UNIX editors. It can contain four kinds of lines: blank lines, comments, environment variable settings, and commands.
Blank lines and spans of white space found in the file are ignored. Use both to keep your crontabs readable and well organized.
You can also use comments to document the timetable and purpose of each
job. To create a comment, simply start a new line with the octothorpe
(#).
Environment variables and commands
Ultimately, cron uses a shell to execute each
command. You can alter or customize the behavior of the shell through
environment variables.
Shell environment variables are easily set in a crontab. Simply type
VARIABLE=value, replacing
VARIABLE with the name of the variable
and value with a value. For example, the
crontab line:
PATH=/usr/bin:/bin:/usr/local/bin |
specifies an ordered list of directories for the shell search path.
The cron daemon predefines five environment
variables:
- The default value for PATH is /usr/bin:/bin.
- SHELL is preset to /bin/sh.
- LOGNAME is initialized to the crontab's owner's user name.
- HOME is set to the home directory of the crontab's owner, such as /home/joe.
- MAILTO is set to the name of the crontab's owner.
To override any of these defaults or to set any variable, simply set the appropriate environment variable in the crontab.
Of course, a crontab can have any number of command lines. Each command line specifies a frequency, a user name (only if the crontab is a system crontab), and a task to run. For example, the command:
5 0 * * * root find /tmp -type f -empty -delete |
deletes all empty files and directories from /tmp (find /tmp -type
f -empty -delete) once per day at 12:05 a.m.
(5 0 * * *). The job runs as root
(root).
A system crontab command must specify a user name to run the task as a
specific user. (Hence, you would probably find the command above in,
say, /etc/crontab.) Per-user crontabs cannot specify a user name; as you
might guess, cron commands for a user always
run as the user. The omission of the user name is the only difference between
a system and user crontab.
As always, the devil is in the details. So, let's look at the many ways you can customize a timetable.
