Using cron basics

At one time cron was easy to describe: It involved only one or two files. All you had to do was edit the files and -- voilà! -- cron did the rest. Now cron has become several files and several programs, and at first glance it seems quite complex. Fortunately, someone was clever enough to create a simplified interface along with the new complexity.

Cron is really two separate programs. The cron daemon, usually called cron or crond, is a continually running program that is typically part of the booting-up process.

To check that it's running on your system, use ps and grep to locate the process.

ps -ef|grep cron 
root    387      1   0   Jun 29 ?     00:00:00 crond 
root  32304  20607   0   00:18 pts/0  00:00:00 grep cron 

In the example above, crond is running as process 387. Process 32304 is the grep cron command used to locate crond.

If cron does not appear to be running on your system, check with your system administrator, because a system without cron is unusual.

The crond process wakes up each minute to check a set of cron table files that list tasks and the times when those tasks are to be performed. If any programs need to be run, it runs them and then goes back to sleep. You don't need to concern yourself with the mechanics of the cron daemon other than to know that it exists and that it is constantly polling the cron table files.

The cron table files vary from system to system but usually consist of the following:

• Any files in /var/spool/cron or /var/spool/cron/crontabs. Those are individual files created by any user using the cron facility. Each file is given the name of the user. You will almost always find a root file in /var spool/cron/root. If the user account named jinx is using cron, you will also find a jinx file as /var/spool/cron/jinx.
  

  
  ls -l /var/spool/cron 
  -rw-------   1  root    root          3768 Jul 14  23:54  root 
  -rw-------   1  root    group          207 Jul 15  22:18  jinx 
  

• A cron file that may be named /etc/crontab. That is the traditional name of the original cron table file.
• Any files in the /etc/cron.d directory.

Each cron table file has different functions in the system. As a user, you will be editing or making entries into the /var/spool/cron file for your account.

Another part of cron is the table editor, crontab, which edits the file in /var/spool/cron. The crontab program knows where the files that need to be edited are, which makes things much easier on you.

The crontab utility has three options: -l, -r, and -e. The -l option lists the contents of the current table file for your current userid, the -e option lets you edit the table file, and the -r option removes a table file.

A cron table file is made up of one line per entry. An entry consists of two categories of data: when to run a command and which command to run.

A line contains six fields, unless it begins with a hash mark (#), which is treated as a comment. The six fields, which must be separated by white space (tabs or spaces), are:

1. Minute of the hour in which to run (0-59)
2. Hour of the day in which to run (0-23)
3. Day of the month (0-31)
4. Month of the year in which to run (1-12)
5. Day of the week in which to run (0-6) (0=Sunday)
6. The command to execute

As you can see, the "when to run" fields are the first five in the table. The final field holds the command to run.

An entry in the first five columns can consist of:

• A number in the specified range
• A range of numbers in the specified range; for example, 2-10
• A comma-separated list consisting of individual numbers or ranges of
  numbers, as in 1,2,3-7,8
• An asterisk that stands for all valid values

Note that lists and ranges of numbers must not contain spaces or tabs, which are reserved for separating fields.

A sample cron table file might be displayed with the crontab -l command. The following example includes line numbers to clarify the explanation.

1     $ crontab -l 
2     # DO NOT EDIT THIS FILE 
3     # installed Sat Jul 15 
4     #min    hr   day   mon   weekday  command 
6     30      *     *     *     *       some_command 
7     15,45   1-3   *     *     *       another_command 
8     25      1     *     *     0       sunday_job 
9     45      3     1     *     *       monthly_report 
10    *       15    *     *     *       too_often 
11    0       15    *     *     1-5     better_job 
$ 

Lines 2 through 4 contain comments and are ignored. Line 6 runs the command some_command at 30 minutes past the hour. Note that the fields for hour, day, month, and weekday were all left with the asterisk; therefore some_command runs at 30 minutes past the hour, every hour of every day.

Line 7 runs the command another_command at 15 and 45 minutes past the hour for hours 1 through 3, namely, 1:15, 1:45, 2:15, 2:45, 3:15, and 3:45 a.m.

Line 8 specifies that sunday_job is to be run at 1:25 a.m., only on Sundays.

Line 9 runs monthly_report at 3:45 a.m. of the first day of each month.

Line 10 is a typical cron table entry error. The user wants to run a task daily at 3 p.m., but has only entered the hour. The asterisk in the minute column causes the job to run once every minute for each minute from 3:00 p.m. through 3:59 p.m.

Line 11 corrects that error and adds weekdays 1 through 5, limiting the job to 3:00 p.m., Monday through Friday.

Now that you know cron basics, try the following experiment. Cron is usually used to run a script, but it can run any command. If you do not have cron privileges, you will have to follow as best you can, or work with someone who has them.

Use the crontab editor to edit a new crontab entry. In this example I am asking cron to execute something every minute.

$crontab -e 
0-59    *    *    *    *    echo `date` "Hello" >>$HOME/junk.txt 
$ 

The sixth field contains the command to echo the output from date (note the reverse quotes around date), followed by "Hello", and also the command to append the result to a file in my home directory, which is named junk.txt.

Close this cron table file. If you have cron privileges and have entered the command correctly, you will receive a receive that the file has been saved.

Use crontab -l to view the file.

$ crontab -l 
# DO NOT EDIT THIS FILE 
# installed Sat Jul 15 
0-59    *    *    *    *    echo `date` "Hello" >>$HOME/junk.txt 
$ 

Change to your home directory, use the touch command to create junk.txt in case it does not exist, and then use tail -f to open the file and display the contents line by line as they are inserted by cron.

$ cd 
$ touch junk.txt 
$ tail -f junk.txt 
Sat Jul 15 15:23:07 PDT Hello 
Sat Jul 15 15:24:07 PDT Hello 
Sat Jul 15 15:25:07 PDT Hello 
Sat Jul 15 15:26:07 PDT Hello 

The screen will update once per minute as the information is inserted into junk.txt.

Stop the display by pressing Control-D.

Be sure to clean up the cron table files by using the crontab -e option to open the cron table file and remove the line you just created.

All commands executed by cron should run silently with no output. Because cron runs as a detached job, it has no terminal to write messages to. However, the best-laid plans of mice, men, and programmers are not without deviations from the expected course, and it is entirely possible that a command, script, or job may produce output or, heaven forbid, some actual error messages.

To handle that, cron traps all the output to standard out or to standard error that has not been redirected to a file, as in the example just tested. The trapped output is dropped into a mail file and is sent either to the user who originated the command or to root. Either way, it conveniently traps errors without forcing cron to blow up or abort.