InformIT: Mac OS X Unleashed

Table of Contents

Housekeeping

The Mac OS X Unix subsystem can schedule tasks for automatic execution whenever you'd like. Like the automatic software installation, you can write your own maintenance scripts that execute at given intervals. In fact, there are already several scripts that help keep your system running clean.

`cron`

The cron process is used to schedule repeating tasks for execution by adding entries to either a user or system crontab file. The system-level file is located in /etc/crontab. The default crontab file looks like this:

#       $NetBSD: crontab,v 1.13 1997/10/26 13:36:31 lukem Exp $
#
# /etc/crontab - root's crontab
#
SHELL=/bin/sh
PATH=/bin:/sbin:/usr/bin:/usr/sbin
HOME=/var/log

#min    hour    mday    month   wday    user    command

# Disabled by default, since it causes disk access every 10 minutes,
# which is useless unless you use at(1).  Enable as needed.
#*/10   *       *       *       *       root    /usr/libexec/atrun

# do daily/weekly/monthly maintenance
15      3       *       *       *       root    sh /etc/daily 2>&1 | tee /var/log/daily

      
   .out   | mail -s "`hostname` daily output"   root
30      4       *       *       6       root    sh /etc/weekly 2>&1 | tee /var/log/weekly

      
   .out  | mail -s "`hostname` weekly output"  root
30      5       1       *       *       root    sh /etc/monthly 2>&1 | tee /var/log

      
   /monthly.out | mail -s "`hostname` monthly output" root

At the start of the file, a handful of environment variables are set (SHELL, PATH, HOME), which are made available to the commands executing from the file. Additional environment variables can be added using the same syntax: <variable name> = <value> .

One special crontab variable is the MAILTO variable, which can be set to a user account name. Output from the crontab commands (errors, and so on) will be sent via e-mail to that user's account.

The body of the crontab file is laid out in six columns, separated by spaces or tabs. These six fields control different aspects of when a command is run:

Minute— The minutes after an hour that a command should be executed (0–59).
Hour— The hour a command should run (0–23).
Day of the month— The day of the month to run the command (0–31).
Month— The month, specified numerically (1–12), or by name that the command should execute.
Weekday— The day of the week the command should execute, set numerically (0–7, 0 or 7 specifies Sunday) or by name.
User— The user ID to use while executing the command.
Command— The command string to execute. This field can point to a shell script or other file to run a sequence of commands.

Fields that contain an asterisk (*) indicate that the command will run whenever the other columns values are matched. For example, assume that there is an asterisk in every column (except for the User and Command fields, obviously):

* * * * * <my user> <my command>

The command will be started every minute, of every hour, of every day, of every day of the week, and so on. In addition, you can add set a command to run at multiple different intervals within a time period without having to use additional lines. Just use integers separated by commas to set off multiple times within one of the columns.

For example, to run a command every ten minutes, you could use

0,10,20,30,40,50 * * * * <my user> 
   <my command>

Even this, however, can be shortened to be a bit more manageable. Regular intervals can be shortened using the syntax */ <interval length> . The previous example, could be rewritten like this:

*/10 * * * * <my user> <my command>

Additions that are made to the /etc/crontab file are read every minute without additional user interaction.

Three scripts are run by default from the Mac OS X /etc/crontab file: /etc/daily, /etc/weekly, and /etc/monthly. As their names suggest, these files are run at repeating intervals each day, week, and month, respectively. They handle cleaning up temporary system files, log rotation, and other menial maintenance tasks. You can take advantage of these files or add additional script files to perform other common tasks.

`cron` for Normal Users

The system-wide /etc/crontab file should be used only for system tasks. Users, how ever, might want to add their own commands and scripts that are executed within their accounts. To do this, a user can create a crontab-style file within his directory. This file should contain all the fields as the previously documented /etc/crontab file, with one notable exception: there is no User field. Any commands executed from a personal crontab file are executed with the permissions of that user.

For example:

*/15 * * * * /Users/jray/myscript.pl

Putting this line in a file gives me a personal crontab that executes a Perl script in my home directory every fifteen minutes.

Unlike the system-level crontab file, personal crontab files are loaded into a privileged system area, rather than being run directly from the file you've created. To load a personal crontab file into the system, use the crontab utility followed by the name of your personal file: crontab <my crontab file> .

Assuming that I've stored my crontab entries in mycrontab, I can load them into the system with

[primal:~] jray% crontab mycrontab

After the file is loaded into the system, you can safely delete the local copy of your crontab file—it is no longer needed. A user can display the loaded crontab information (and thereby regenerate the original file) by typing crontab -l:

[primal:~] jray% crontab -l
# DO NOT EDIT THIS FILE - edit the master and reinstall.
# (mycrontab installed on Sun Jul  1 10:01:20 2001)
# (Cron version — $FreeBSD: src/usr.sbin/cron/crontab/crontab.c,v 1.12
#  1999/08/28 01:15:52 peter Exp $)
*/15 * * * * /Users/jray/myscript.pl

A user can also use the -e option to edit her currently stored crontab information, or use -r to remove it entirely.

Limiting Access to `cron` Services

On a system with a large number of users, it isn't necessarily a good idea to give all of them access to cron services. You might find that your poor system performance is due to a few hundred copies of SETI@home that start automatically every night. To limit access to the crontab command for adding personal crontab entries, use either /var/cron/allow or /var/cron/deny.

As you might infer, the allow file controls who is allowed to access crontab. Adding entries to this file will deny access for anyone who isn't listed.

Likewise, the deny file, if it exists, will provide access to crontab for anyone who isn't listed.

This isn't intentionally tricky, but it is important to note that the act of creating one of these files implicitly denies or allows access to all the accounts on the system. Obviously, you should not be running a system where both files exist simultaneously because it leads to an ambiguity of what happens to "everyone else" who isn't listed in one of the files.

Over time, you'll discover that there are small tasks you carry out on a day-to-day basis. Using the power of the cron daemon along with shell scripts, Perl, or AppleScript can automate many of these processes.

Summary | Next Section

Previous Section

Housekeeping

cron

cron for Normal Users

Limiting Access to cron Services

`cron`

`cron` for Normal Users

Limiting Access to `cron` Services