Automating Processes with the cron Scheduler Daemon

Automating Processes with the cron Scheduler Daemon

Now that you've seen how to manipulate processes directly, you're ready to examine how processes can be executed automatically without any intervention on your part. Automating tasks with the scheduler allows FreeBSD to perform daily security audits and system status updates, regularly update its runtime databases, flush log files, and perform as many other tasks as an administrator can think of. Some operating systems attach schedulers to individual applications (such as the Software Update tool in Mac OS X), but the advantage of FreeBSD and other UNIX-like systems is that the scheduler is an independent daemon that can run any command-line program or set of programs on any periodic schedule you can think of.

The scheduler in FreeBSD, as in most UNIX-type systems, is called cron. FreeBSD's cron program was written by Paul Vixie, and it's the standard version used in most distributions of Linux and other similar systems. Like any standalone daemon, it runs all the time and looks at its input files (called crontab files) each minute to see whether they have changed or contain a task it needs to execute that minute. The cron process itself never needs to be restarted; it will automatically read in any changes when it wakes up every minute.

A global crontab file (/etc/crontab) contains scheduled jobs executed by the system, and a special directory (/var/cron/tabs) enables individual users to create their own crontab schedule files. It can be tempting to add your own scheduled jobs to the /etc/crontab file, but, as with /usr/local/etc/rc.d versus /etc/rc.local (refer to Chapter 14, "System Configuration and Startup Scripts"), you really should leave /etc/crontab untouched (so it can be safely overwritten by later upgrades) and create new jobs in root's personal crontab file in /var/cron/tabs. You'll see how to do this in a moment.

Anatomy of a crontab File

Let's take a look inside a user's individual crontab file. Here's /var/cron/tabs/frank:

[View full width]
# DO NOT EDIT THIS FILE - edit the master and reinstall. # (/tmp/crontab.qx7aeeMvoH installed on Mon Feb 7 11:47:00 2005) # (Cron version -- $FreeBSD: src/usr.sbin/cron/crontab/crontab.c, v 1.19 2002/10/01 22:59 :11 dd Exp $) 0 3 1,15 * * cat ~frank/faq.txt | mail -s "FAQ Auto-Post" [e-mail]

This file has one item in it: a task to send a text file into mail to be sent out to a mailing list. The task will be executed at 03:00 on the 1st and 15th of every month. How is this schedule specified? It's done with the first five fields of the whitespace-separated data line. (The first three lines are auto-generated comments and are not processed by cron.) The fields are shown, in order, in Table 15.2.

Table 15.2. Date and Time Fields in a crontab File

Field	Allowed Values
Minute	059
Hour	023
Day of month	131
Month	112
Day of week	07 (Sunday = 0)

For instance, to create a task (we'll use the simple ls for these examples) that executes every night at 1:00 a.m., use the following syntax for the five fields:

0      1      *      *      *      ls

To run the same task only on Mondays, use this:

0      1      *      *      1      ls

A task that runs at the top of every hour throughout the month of March would be specified like this:

0      *      *      3      *      ls

Any field can have multiple numbers separated by commas or can contain a range (for instance, 1-10). You can also use an asterisk (*) in a field to specify every occurrence of that interval. The month and weekday (fourth and fifth) fields can also use symbolic namesthe three-letter abbreviations for month or weekday names. Names can also be listed as comma-separated strings, although they can't be used in ranges. In the fifth (weekday) field, 0 and 7 are Sunday.

Note

If you want to run a command every n minutes, or every n hours, you can do that by specifying a "step" value (for example, */n). In the minute field, */5 would translate to "every fifth minute," or the equivalent of 0,5,10,15,20,25,30,35,40,45,50,55. See man 5 crontab for further details on schedule formatting.

You can also use shorthand strings in place of the first five fields to specify certain oftenused schedules, as shown in Table 15.3.

Table 15.3. Examples of Symbolic Scheduling Intervals

String	Equivalent
@reboot	Run once, at startup
@yearly	0 0 1 1 *
@annually	Same as @yearly
@monthly	0 0 1 * *
@weekly	0 0 * * 0
@daily	0 0 * * *
@midnight	Same as @daily
@hourly	0 * * * *

You can use shorthand strings, for example, to specify a task to occur every night at midnight. The following two lines are equivalent:

@midnight      ls 0       0        *       *       *       ls

After the schedule fields, the formats of the /etc/crontab file and the individual crontab files diverge slightly. The global /etc/crontab file has an extra field before the command fielda who fieldthat specifies which user should execute and own the process:

1       3       *       *       *       root periodic daily

The command field can be as complex as you like; fill it in exactly as you would a command entered at the command line. You can even use a semicolon (;) to separate multiple commands that you want to run sequentially as part of the same automated job. It's important to note that for commands executed from /etc/crontab, cron will not assume the path of the user specified in the who fieldthere's a PATH statement at the top of the file that lists only a few basic system directories. This means you need to give the full path to any command you run that isn't in that path; otherwise, cron won't be able to find the programs to run.

If there's any output from any program executed by cron, that output is gathered into a mail message and sent to the owner of the crontab file (or the owner of the scheduled task for /etc/crontab items).

Creating and Editing crontab Files

It's easy enough for you to edit /etc/crontab as root and to add any schedule items you want. Because you should avoid editing /etc/crontab if at all possible, however, you need to understand the individual crontab files and how to create and manage them.

Because each crontab file goes into a central directory (/var/cron/tabs) and is owned by its creator with permissions 0600, a security mechanism is in place to allow users to create and edit their own files there without compromising others' files. This mechanism is the crontab program:

# crontab e

Here's how to edit Frank's crontab file if you're root:

# crontab -e -u frank

Much like the chfn and edquota tools you saw in Chapter 13, "Users, Groups, and Permissions," crontab works by invoking the editor specified in the VISUAL environment variable (or the EDITOR variable, if VISUAL isn't set). The contents of the file (minus the first three comment lines) appear in the editor. After you make your changes, save it and exit. The temporary file, which resides in /tmp while you're making your changes, is copied into /var/cron/tabs, and the header lines are added. The crontab file will be active the next time cron looks at it, at the top of the minute.