cron allows you to schedule programs for periodic execution. For example, you can use cron to call a particular site every hour, to clean up editor backup files every night, or to perform any number of other tasks. However, cron is not a general facility for scheduling program execution off-hours; use the .
With, cron can send program output to a log file or to any username via the .
The cron system is serviced by the cron . What to run and when to run it are specified to cron by crontab entries, which are stored in the system's cron schedule. Under BSD, this consists of the files /usr/lib/crontab and /usr/lib/crontab.local ; either file may be used to store crontab entries. Both are ASCII files and may be modified with any text editor. Since usually only root has access to these files, all cron scheduling must go through the system administrator. This can be either an advantage or a disadvantage, depending on the needs and personality of your site.
Under System V (and many other versions of UNIX), any user may add entries to the cron schedule. crontab entries are stored in separate files for each user. The crontab files are not edited directly by ordinary users, but are placed there with the crontab command (described later in this section). [In my experience, the cron jobs are run from your home directory. If you read a file or redirect output to a file with a, that'll probably be in your home directory. Check your system to be sure. -JP ]
crontab entries direct cron to run commands at regular intervals. Each one-line entry in the crontab file has the following format:
Spaces separate the fields. However, the final field, cmd , can contain spaces within it (i.e., the cmd field consists of everything after the space following weekday ); the other fields must not contain spaces. The username field is used in the BSD version only and specifies the username under which to run the command. Under System V, commands are run by the user who owns the crontab in which they appear (and for whom it is named).
The first five fields specify the times at which cron should execute cmd . Their meanings are described in Table 40.1 .
These fields can contain a single number, a pair of numbers separated by a dash (indicating a range of numbers), a comma-separated list of numbers and ranges, or an asterisk (a wildcard that represents all valid values for that field).
The first entry displays the date on the console terminal every fifteen minutes (on the quarter hour); notice that multiple commands are enclosed in parentheses in order to redirect their output as a group. (Technically, this says to run the commands together in a 40.5 explains, try not to schedule your jobs at often-chosen times like 1:00 a.m., 2:00 a.m., and so on; pick oddball times like 4:12 a.m. -JP ].) The second entry runs /usr/lib/atrun every ten minutes from 7:00 a.m. to 6:00 p.m. daily. The third entry runs a find command at seven minutes after midnight to remove all .bak files not accessed in seven days. [To cut wear and tear and load on your disk, try to . Also, as article
The fourth and fifth lines run a shell script every day, at 4:12 a.m. and 2:22 a.m., respectively. The shell to execute the script is specified explicitly on the command line in both cases; the system default shell, usually the Bourne shell, is used if none is explicitly specified. Both lines' entries redirect standard output and standard error, sending it to a file in one case and mailing it to root in the other.
The sixth entry executes a C shell script named uu.weekly
, stored in
, at 3:30 a.m. on Monday mornings. Notice that the command
format - specifically the output redirection - is for the Bourne shell even
though the script itself will be run under the C shell.
The seventh entry runs on the third Monday of every month; there's more
The final entry
would run the command /usr/lib/newsbin/news.weekend
at 2:30 a.m. on
Saturday and Sunday mornings if it were not disabled with a
The fourth through sixth entries illustrate three output-handling alternatives: redirecting it to a file, piping it through mail, and discarding it to. If no output redirection is performed, the output is sent via mail to the user who ran the command.
The cmd field can be any UNIX command or group of commands (properly separated with semicolons). The entire crontab entry can be arbitrarily long, but it must be a single physical line in the file.
One problem with the crontab syntax is that it lets you specify any day of the month, and any day of the week; but it doesn't let you construct cases like "the third Monday of every month." You might think that the crontab entry:
12 5 15-21 * 1
would do the trick, but it won't; this crontab
entry runs your
command on every Monday, plus the 15th through the 21st of each month.
An answer from Greg Ubben is shown in the seventh entry.
He uses the
12 5 15-21 * * test `date +\%a` != Mon || /usr/local/etc/mtg-notice
He did it in that "backwards" way so the cron job's exit status would be 0 (success) in the case when it doesn't execute mtg-notice . You may need that technique, too.
The cron command starts the cron program. It has no options. Once started, cron never terminates. It is normally started automatically by one of the system initialization scripts. cron reads the crontab file(s) every minute to see whether there have been changes. Therefore, any change to its schedule will take effect within one minute.