Linux / BSD, Understanding Cron

Cron is one of the basic facilities available on your Linux installation, and as a matter of fact, on most every UNIX box. In a nutshell, cron is a systemwide scheduling daemon (a 'daemon' is a service that runs on your Linux machine, normally in the background where you don't notice its presence) that takes a configuration file called a 'crontab', and runs daemons or other applications depending on the time and date you set. It's very necessary for some system applications to run at certain invervals, and you can utilize it as a regular user to run things for you as well. We'll go through the necessary steps to edit your own crontab, the systemwide crontab, and the protocol used in them.

The 'crontab' is basically a plain text file that you can create on your own, and there is a corresponding 'crontab' command that's used to edit these files and initialize them with the cron daemon. Once your crontab is complete, it will be loaded into memory and used by cron, which will check once a minute to see if there is anything that needs to be run. You can have cron run things for you once a minute, once an hour, or even once a month. This is very useful for having backups run at night while no-one is using the machine, or to run a script once an hour or so that checks on a machine's status and emails you the results somewhere else. The basic layout will show entries for minute, hour, day of month, month, and day of week. You can customize each crontab entry as shown below:

Code:

# example crontab entry 1    #command


# minute | hour | day of month | month | day of week


0-59/1 * * * *    exec /path/to/somecommand

In the example shown above, the command will be run once a minute, every hour of every day of the month. You'll notice that the minute's entry is specified, but the rest of the time entries are show with an 'asterisk' to tell cron it's meant to be all the time. If the crontab entry is incomplete for some reason, or if the command you enter on the line is missing or gives an error, you should receive an email message notifying you of the fact so you can correct it. In the minute entry, you'll note that it's entered as '0-59', for every minute in a 60 minute hour, counting up from '0'. All the conventions used in the entries are similar, '0-23' for hours, '0-31' for day of month, '0-11' for month and '0-6' for day of week; Sunday being '0' as the first day of the week. The slash '/1' tells the entry that it will be once a minute. You can break up hours into 1 minute chunks, 10 minute chunks, etc. by using this. The 'exec' entry isn't absolutely necessary, but I find it useful in seperating the time entry from the actual command you wish to execute. The command that follows can be anything; a script you've created or a standard daemon or application available with your install. You must use 'absolute paths' when referring to the entry to be executed, you can't use '~/bin/script.sh', it must be '/home/username/bin/script.sh' in other words.

Running as Root

When you want to edit the systemwide crontab, simply login as root user and issue the command 'crontab -e'. The '-e' switch tells crontab to edit the default systemwide file. You can also use the '-u username' switch to edit specific users crontab files, which is useful if you're a UNIX system administrator trying to track down errant processes that users are executing via the cron daemon. Once you've issued this command, the default editor (vi on most systems) will open and you can edit the file at will. When it's completed, saved and you exit the editor, the crontab will be automatically read in and used immediately. Depending on what time you've set your entry to run, it may be wise to have it run once an hour or even once a minute until you're absolutely sure the command you're using will work. Once you've debugged the entry, set it and forget it.

Running as a user

You can similarly edit your own crontab with the same command 'crontab -e', only this time it will affect you alone. The commands you specify must be executable by you, and you must have permission to use the application or command specified. This is particularly useful for creating your own shell script or perl script and running them whenever you want, without having to be at the terminal. Another useful trick is to create your crontab beforehand, editing a plain text file with the editor of your choice, and just pointing the crontab command at it like so: 'crontab /path/to/crontab-file'. I personally keep my cron entries in ~/.crontab so they're easily accessible, and when I do frequent backups of my /home/user directory, the crontab is backed up right along with everything else.

Debugging

Of course, it'd be a fluke if the first time you edited your own cron entry, it actually worked perfectly. There is normally a little debugging involved, whether it's to get the time just right, or maybe you've misspelled the command path to run, etc. You will know immediately if the entry doesn't work, because cron is very good at sending you an error about this. Someone we know recently found out the hard way when the command they wanted to execute once a minute was deleted from the system, and cron sent an email once a minute for a day or so notifying them of the problem. Needless to say, if you have a full days worth of messages waiting in your inbox for you, it's worth spending a few minutes extra to debug your crontab! Sometimes you'll run into issues where the time is correct, the command is correct, but it spits out an error code anyway. Perhaps the command normally sends output to 'stdout' (standard output channel,viewed when you run it from the prompt) and you're sent a message by cron with the results. A neat trick is to redirect the output either to /dev/null (sort of the system's 'trashcan') with "2&1> /dev/null". You might also wish for it to be logged, as shown in the example below:

Code:

# example crontab entry 2 - debugging


# min | hr | dom | mon | dow    # command


# '2' is the shell's standard error channel


# '1' is the shell's standard output channel


# will execute once an hour, sending any output or errors to '/dev/null'


0 * * * *    exec /path/to/somecommand 2&1> /dev/null


# will execute once a day, sending any output to a logfile


0 0 * * *    exec /path/to/someothercommand 2&1> /path/to/logfile

You'll note in the above example, also, that I've used '0' for the minute and hour entries. This tells cron that the once-an-hour and once-a-day entry will be executed on the hour (minute entry '0') or when the clock rolls over at midnight (hour entry '0'). You could, of course, have it run at any time we wanted, let's have a quick example that will execute once a month at exactly 1:30 AM on the 10th.

Code:

# example crontab entry 3 - setting a specific time


# min | hr | dom | mon | dow    # command


# executes on the 10th of every month, at 1:30 am


30 1 10 * *

The minute entry is '30', the hour entry '1' and the day of month entry is '10'. The other entries are marked with an asterisk so it runs every month, regardless of the day of week. Please remember that we're on military time with the computer's clock, so 1pm would be written as '13'.

In closing

I sincerely hope this tutorial has been useful to summarize the basics of what cron can do for you. Please also read the manpages for both cron and crontab, by issuing the commands 'man cron' and 'man crontab' respectively. The methods for editing the crontab file should be outlined in the #5 crontab manpage, viewed with 'man 5 crontab'. Luck!

(printer friendly format)

	Page 1 of 1