Each time and day column in the crontab file can contain a single number anywhere in the range of valid numbers, two numbers separated by a minus sign to show an inclusive range (such as 1–5 to show one through five), a list of numbers separated by commas to mean all of the values explicitly specified, or an asterisk meaning all legal values.

Let’s look at the example of a crontab file again to see how this works. In the following example there are three different processes specified:

20  1  *  *  *   /usr/bin/calendar -

0  2  1 *   0   /bin/organize_data

10,30,50  9-18  *  *  *   /bin/setperms

The first command is /usr/bin/calendar - (the hyphen is an important part of the command). This process is executed at 20 minutes past 1 in the morning (a 24-hour clock is used), every day of the week, and each day of the year. The asterisks mean all values, hence the “each and every” meaning.

At 2:00 a.m., a script file called /bin/organize_data is executed on the first day of every month (the 1 in the third column) and every Sunday (the 0 in the fifth column). If the first day is a Sunday, it executes only once, of course.

The third line shows that a script called /bin/setperms runs at 10, 30, and 50 minutes past the hour every hour between 9:00 a.m. and 6:00 p.m. (or 18:00), every day of the week.

The entries in a crontab file do not have to be in any special order. As long as each entry is on a line by itself and has all six fields specified properly, cron organizes the information for its own use. If you have an error in the crontab file, cron mails you a notice of the problem when it processes your file. (This can be annoying if you have the entry with the error set to execute often because cron will mail you each time it tries to execute the entry and finds a problem. Your mailbox quickly gets filled with cron error messages.)

It is best to keep the crontab files in your home directory and name them crontab, unless you want to have several versions, in which case you can use any naming convention you want. Keeping the names simple, however, helps you identify which file you want cron to execute.

Submitting and Managing crontab Files

Now that you have written your crontab file, you can submit it for cron to execute. When you submit a crontab file, a copy of the file is made and kept in a cron directory, usually /usr/spool/cron/crontabs. The file will have the name of the submitting user (for example, a crontab file submitted by yvonne will have the name /usr/spool/cron/crontabs/yvonne. Any crontab files submitted by the superuser will usually have the name root.

To submit your crontab file to cron, use the crontab command followed by the name of the file with the cron commands in it. For example, the command submits the file called crontab in the current directory to cron:

crontab crontab

If you had previously submitted a cron file, it is removed and the new file is used instead.

---

Tip:  
Always submit a change to cron using the crontab file and an edited ASCII file. Never make changes to the file in /usr/spool/cron/crontabs.

---

You can see what you have submitted to cron by using the -l (list) option. This shows all the crontab entries that the cron utility knows about (essentially displaying the contents of the file with your username from /usr/spool/cron/crontabs). For example, the command shows all cron tasks for the user who submits the command:

crontab -l

If you want to remove your crontab file and not replace it, it is easily done with the -r (remove) option. This simply erases the file with your filename from the /usr/spool/cron/crontabs directory. To remove your crontab file, issue the command

crontab -r

Finally, crontab lets you call up your current cron file and start an editor (the default editor as defined by your environment variables or a system default variable) by using the -e (editor) option. When you issue the following command crontab reads your existing crontab file and loads it into the default editor (such as vi):

crontab -e

When you save the file, it is submitted to cron automatically.

Changes to the crontab file are usually effective within five minutes at most because cron reads the contents of the /usr/spool/cron/crontab file at least once every five minutes and often more frequently than that (most Linux systems have cron check the directories every minute). This also means that execution of a process you submit to cron can sometimes be delayed by a few minutes, so don’t rely on cron to be exactly on time. The more heavily loaded a system is, the more delay in execution that you can expect.

On some systems, system administrators can log all cron usage by modifying an entry in the file /etc/default/cron. One line in the file should contain the variable CRONLOG. Set the value equal to YES, and cron logs every action it takes to the file /usr/lib/cron/log. Not all versions of Linux allow cron logging. If you do enable cron logging, check the log file frequently because it can grow to a large size quite quickly.