Volume Number: 21 (2005)
Issue Number: 3
Column Tag: Basic Admin Skills

Cron and Crontab In-Depth

by Josh Wisenbaker

Making sense of 30 4 1,15 5

What's this all about?

One of the most essential, and misunderstood, UNIX admin skills is being able to effectively use the cron daemon by maintaining your crontab files. The big problem is that the format of the crontab files can be very hard to grasp at first. Full of bizarre looking statements such as "30 4 1,15 5", the crontab scheduling statements can put off many users before they begin. By the end of this article it is my hope that you will not only have a firm grasp of the crontab format but also have some good ideas of what you can do with cron.

Cron

O.K. here we go. Cron is the name of the program that runs scheduled tasks on your Mac. For example you can use cron to call a command to upload files to a web server, fetchmail from a remote server, roll and archive log files, or clear cache files. In general, any non-interactive task can be easily automated with cron.

Like most things on Mac OS X, cron is almost, but not quite, like cron on other UNIX systems. The main difference is that it is started by the /System/Library/StartupItems/Cron startup item rather than the /etc/rc boot script. Other than that, you can treat cron on Mac OS X the same as you would on any other FreeBSD or Linux type system.

When cron runs a command or script it can output the results to a log, e-mail them to a user, or just discard them and not bother you with the details.

It does all this by reading a file, called a crontab, once a minute to see what needs to be run and when. There can be several crontab files on the system. By default there is only the system crontab located at /etc/crontab. This file contains things like when periodic should run to perform the daily, weekly, and monthly scripts. Each user on the system can also have a crontab file so that non-admin users may schedule tasks as well and these are stored in /var/cron/tabs/<username>. It should be noted however that the format of the system crontab is slightly different than that of the user crontabs and the methods used to edit them are very different.

Crontab Demystified

The Basics

Before we take a look at how to edit the crontab files let's take a moment to get the basic formatting figured out. That way when you open /etc/crontab for the first time it will make sense to you. Although it seems mystical at first, the format for a crontab is actually very simple. It breaks down like this:

minute hour day-of-the-month month day-of-the-week command

The values are separated by white space and the final value, command, may contain spaces of it's own. Let's look at the five values that make up the time to run section...

For the any of the settings you can use numbers starting at 0 and you can optionally use names for the month and day-of-the-week settings thanks to Mac OS X's FreeBSD roots. (Really this is due to the fact that FreeBSD uses an enhanced version of cron, written by Paul Vixie.) When using the names of months or days just use the first three letters in a case-insensitive fashion. A "*" is a wildcard that means first-last and matches anything. So let's say we want to schedule a task to run on the hour, every hour.

0 * * * * command

Huh? How does that work? Easy. The 0 minute is the top of the hour. The wildcards match all other possibilities. So it breaks down to minute 0 of every hour, of every day, of every month, every day of the week. Let's look at another one. Let's say you want to run something every Sunday at 12:15 am.

15 0 * * sun command

So you are telling it run on minute 15, of the 0 hour (midnight), every day of the month, every month, on Sunday. Notice here that you can use 'sun' for Sunday. You could also use 0 or 7 for Sunday if so inclined. Let's take a look at one more basic example. Pretend we want to run a task at the beginning of each New Year.

1   0   1   1   *   command

Cron will interpret this as January 1 at 12:01 am every year. Just because it is a repeating task it doesn't mean that it needs to repeat very often. If you want to start spacing your jobs out in intervals larger than a year though you will need to take care of that in the command or script that you call from cron.

Step Values, Ranges, and Multiples

If we were restricted to simple schedules like the ones just given, cron would not be very flexible. Luckily we can get a bit more creative with our crontab entries. Say that you've decided that you need a task to run at 12:15 am on both Sunday and Tuesday nights. You could make multiple crontab entries or use a value list.

15 0 * * 0,2 command

Will accomplish our desired scheduling with only one entry. Notice here that we used the numerical values for the days although "sun,tue" would work as well. A second option at our disposal is the step value.

If you wanted something to run every two hours you could specify "0,2,4,6,8,10,12,14,16,18,20,22" for the second field but that is really messy. Luckily we can use a step value to make this easier and arrive at the same result with "*/2". So let's say you want to make something that runs every other month on Sundays at 4:32 am...

32 4 * */2 sun command

You can also use a range in place of a list. Rather than type "9,10,11,12,13,14,15,16", just use "9-16".

0   9-16   *   *   *   command

This will run our command every day, on the hour, from 9:00 am to 5:00 pm. Since Mac OS X is a FreeBSD based system we can combine ranges, lists, and step values in a single crontab entry. Building on the last example:

0   0-3,9-16/2   *   *   *   command

Will run our command every day, on the hour, from 12:00 am to 3:00 am and again every other hour from 9:00 am to 5:00 pm. Systems that do not use the Vixie cron would choke on this.

More BSD Family Perks

Since Mac OS X is FreeBSD based we can use some handy shortcuts. Remember our first example, '0 * * * *' that ran a task every hour? Well, you could also just say

@hourly command

Isn't that nice? You can also use @reboot (Once on startup), @yearly (0 0 1 1 *), @annually (same as @yearly), @monthly (0 0 1 * *), @weekly (0 0 * * 0), @daily (0 0 * * *), and @midnight (Same as @daily).

Another set of options is available to us as well in the form of environment variables. You can use the SHELL variable to override the default setting of /bin/sh. Usage is simple:

SHELL=/bin/bash

Just place this, or any of the following variables, at the beginning of your crontab. While the SHELL variable is a bit obscure to many administrators, the PATH, MAILTO, and HOME are a bit more familiar. By default cron will just use the path defined for the owner of the crontab but you can use the PATH variable to override it...

PATH=/etc:/bin:/sbin:/usr/bin:/usr/sbin

You can use the HOME variable in a similar fashion.

HOME=/var/log

By far the most useful environment variable we can define is MAILTO and it has a few usages. By default cron will e-mail the output and results of commands to the owner of the crontab file. We can modify this behavior in two different ways:

MAILTO="josh"

will redirect all mail for the crontab to the user named "josh" and

MAILTO=""

will suppress any mail from the crontab at all. You may find this option useful for a crontab file whose commands that are logged, but do not need to be mailed to anyone.

Command time

OK, now that we know how to schedule something what can we do? Well, anything you want! You can run single commands or scripts and with advanced Mac OS X features like osascript you can even run AppleScripts to drive things like Photoshop. There are only a few things to keep in mind when typing your commands with the main one being that it must be all on one line. If you need to use a newline for your command you can embed a "%" to indicate this. Take a look at the following example.

0 0 2 2 * mail -s "B-Day!" josh%Hey!%Happy birthday Josh!%

This will produce an e-mail with the appropriate newline returns in it. If you want to actually use the "%" character in your command you will need to escape it with a backslash.

You can also string together multiple commands with pipes and semicolons just as you would in the Terminal. If you wanted to get a daily update from the login accounting systems (Don't confuse simple commands like ac and last with the recently released Solaris BSM auditing tools from Apple.) via e-mail you could use the following entry.

0 10 * * * (ac -p; echo; last | tail)| mail -s "Login Accounting" admin@foo.com

Notice that the pipes work just like you would expect them to and the parenthesis are used to group the output of multiple commands into one result. It's also worth noting that the output of the ac and last commands will be sent to admin@foo.com but the report that the command was run will be sent to whoever owns the crontab or a user specified with the MAILTO variable.

So far all of these examples are fairly trivial one-line commands, but that doesn't mean one-liners can't be powerful. If you support designers using Adobe Illustrator then you have run into Adobe font cache issues. Wouldn't it be nice if those nasty things just magically disappeared each night?

15 0 * * * find -x / -type f -name 'AdobeFnt*.lst' -exec rm -f {}\;

If you add this to root's crontab or the system crontab then the stupid Adobe font caches vanish every night at 12:15 am.

You can only stretch one command so far though, so you will find times when you need to resort to calling a shell script with cron. Here is a simple script I use to backup my home folder if a particular FireWire drive is connected using psync.

#!/bin/bash

if [ -d /Volumes/TinyDrive/Backup ]
then
/usr/local/bin/psync -d /Users/josh\ /Volumes/TinyDrive/Backup/josh
exit 0
else
exit 0
fi

I just call this once an hour with cron and my home folder stays backed up safe and sound.

Extra command tidbits

As I mentioned earlier, cron sends an e-mail to the owner of the cron with the results of each job that runs. But what if you don't want any output from a particular command? The easiest way to snuff the results of one command is just to send the output to /dev/null. When I run my backup shell script I send both stdout and stderr to the bit bucket...

@hourly /backup.sh 2>&1 /dev/null

This way it never bugs me with the results. If I were just to send stdout to /dev/null then it would just send me the errors. Redirecting the output of a specific command is much more selective than using a MAILTO="", as that option will kill all output from the crontab.

There is one more, really cool, Apple added feature. Let's say that I have a sync operation that runs every 15 minutes. Now if it is critical data I probably don't want this to run if the power is out and the system is on the UPS. If you prefix a command with '@AppleNotOnBattery' then cron will not execute the command if not on AC power. So,

@AppleNotOnBattery command

is all you need.

Editing your crontab files

There are two distinctly different types of crontab files on Mac OS X, the system crontab and user crontab files. They have slightly different formatting, but are edited in very different ways. Let's take a look at the system crontab first.

The system crontab

Located at /etc/crontab, the system crontab is typically used for system maintenance activities such as the periodic command. One of the nice things about the system crontab is that it is commented and the first thing you should notice is that it has an extra field in the entry lines with a "who" variable between the weekday and command. Since any particular user does not own this crontab you must specify whom the command will have as its owner. Take a look at this example.

15 3 * * *  root    periodic daily
15 0 * * * mailman    /usr/share/mailman/bin/check_perms

The first command is the daily run of the periodic command that all Mac OS X computers come with. Notice it runs as root. The second command checks the permissions on the mailman install of a Mac OS X Server. Notice it runs as the mailman user. For security reasons you should keep the amount of tasks performed as root to a minimum. In this case the mailman user has the rights it needs to get the job done, and it owns the files in question, so it makes sense to run this command with that user.

To edit the system crontab you simply open it with your editor of choice. Beware of line wraps though when using tools such as pico. (Since pico is such a popular editor I will point out that running it with a -w flag will minimize line wraps.) Remember that this file is owned by root, so you will need to use sudo to edit it. Simple eh?

User crontab files

One of the nice things about cron is that any user on a system may use it. However, it should be obvious that you don't want regular users messing about in the system crontab. Luckily there is a system provided to get around this issue and each user may have an individual crontab file. The individual user crontab files are kept in /var/cron/tabs/<username> and, unlike the system crontab, they may not be edited directly. Instead you must use the crontab command.

The crontab command has a few basic usages. To edit your personal crontab simply use:

crontab -e

and your crontab file will open up for editing. When it opens the crontab it does so using the default editor, which unless you have changed it, is vim. (Now some of you will yell at me for it, but vi is a six headed beast to me and I changed my default editor to pico by adding "export EDITOR=pico" to my .profile. The only real requirement of the editor is that it can edit the file in place without unlinking it.) Once the file opens up, just create your entries and save them. That's it! Cron will evaluate all the crontab files on the next minute and execute anything that it finds. No HUPing needed.

You can also use the crontab command to list your existing entries with a -l flag or remove your crontab with a -r flag. If you choose to use the remove flag the system will prompt you for approval before deleting the file.

If you have administrator rights you can edit the crontab files of other users as well. If you remember our mailman example from before, we could just make that entry directly in the mailman user's crontab file by using the -u flag.

sudo crontab -u mailman -e

Now mailman's crontab will open and you can add jobs to it as you see fit. Note that if you simply used "sudo crontab -e" that it would open root's crontab file. This can get confusing though and I would recommend that you always specify the user when editing a crontab file other than your own.

Security issues

Now that you know that any user can create and use a crontab file your admin senses should be tingling, alerting you to the danger of unrestricted cron jobs. Out of the box there is nothing stopping a user from leaving a time bomb of a command in their crontab file. You might not even realize it is there until it unleashes its havoc at some later date. Imagine having 5000 users in your system that have shell access, but you only need root, bugzilla, and mailman to have access to cron. What can you do? The solution is simple as cron, like many other daemons, has a facility for allow and deny files.

Located at /var/cron/allow and /var/cron/deny, these files provide a simple way to restrict crontab usage. If the allow file exists, users must be listed in the file in order to use crontab. If your system has a deny file but no allow file, then users must not be listed in the deny file in order to use crontab. By default, neither of these files exists. On a basic Mac OS X system this allows unfettered access to the crontab command.

By using an allow file without a deny file you can easily restrict crontab to just a few users, thus making your Mac OS X system much more secure.

Wrapping up

So that's it! Armed with your newfound cron and crontab skills you can begin to automate all sorts of tasks on your Mac OS X systems. Backups, file archiving, software updates, and trash patrol can all be automated. The more you have the system work for you, the less work you need to do for it and isn't that the goal of every sysadmin?

Josh Wisenbaker is the Sr. Systems Engineer for a Macintosh IT company in Winston-Salem, NC. He is better known for his work as half of www.afp548.com. You can reach him at macshome@afp548.com.