Well, we added the entry, but it probably doesn’t say much. So, let’s take a look at the actual entry. Despite its appearance, each crontab entry consists of only six fields. The first five represent the time the job should be executed and the sixth is the actual command. The first five fields are separated by either a space or a tab and represent the following units, respectively:

• minutes (0-59)
• hour (0-23)
• day of the month (1-31)
• month of the year (1-12)
• day of the week (0-6, 0=Sunday)

To specify all possible values, use an asterisk (*). You can specify a single value simply by including that one value. For example, the second line in the previous example has a value of 10 in the first field, meaning 10 minutes after the hour. Because all of the other four time fields are asterisks, this means that the command is run every hour of every day at 10 minutes past the hour.

Ranges of values are composed of the first value, a dash, and the ending value. For example, the fourth line has a range (1-5) in the day of the week column, meaning that the command is only executed on days 1-5, Monday through Friday.

To specify different values that are not within a range, separate the individual values by a comma. In the fourth example, the hour field has the two values 10 and 14. This means that the command is run at 10 a.m. and 2 p.m.

Note that times are additive. Lets look at the example above:

The command is run 15 minutes after hour 10 and 14 on, Monday through Friday. Assume we wanted it to only run on on the 1st and 15, but only of they were a weekday. You might be tempted to do something like this:

As of this writing, cron cannot be configure to create complex conditions. If you need to schedule jobs of this nature, take a look at the Open Source Job Scheduler.

Task:

The crontab entry can be defined to run at different intervals than just every hour or every day. The granularity can be specified, for example, to every two minutes or every three hours without having to put each individual entry in the crontab.

Lets say we wanted to run the previous command not at 10 minutes after the hour, but every ten minutes. We could make an entry that looked like this:

This runs every 10 minutes: at the top of the hour (0 minutes after), 10 minutes after, 20 minutes after, and so on. Although this works, it could be done simpler by creating an entry like this:

This syntax may be new to some administrators, but is still pretty straightforward. The slash (/) says that within the specific interval (in this case, every minute), run the command every so many “units”. In this example, the units are minutes, so we are saying to run the job every 10 minutes. Specifying it as “*/5” would say to run it every 5 minutes.

1. login as the root user
2. Issue the command
   crontab -l -u jimmo >/tmp/crontab.jimmo
3. Edit the file /tmp/crontab.jimmo using vi.
4. Append the following line to the bottom of the file:
   */10 * * * * /usr/local/bin/command
5. Save the file and exit vi.
6. Active the new cron file with the command:
   
   crontab -u jimmo /tmp/crontab.jimmo

Task:

We can combine both intervals and range.For example, if the job was to run every 10 minutes, but only between 8 AM and 5 PM, Monday through Friday, that is normal work hours. As we mentioned above, a range is specified by the start and end values separated by a dash, so from 8 AM to 5 PM, it would look like this:

Note that in this case are using a 24 hour clock, so 5 PM is 17.

1. login as the root user
2. Issue the command
   crontab -l -u jimmo >/tmp/crontab.jimmo
3. Edit the file /tmp/crontab.jimmo using vi.
4. Append the following line to the bottom of the file:
   */10 8-17 * * * 1-5 /usr/local/bin/command
5. Save the file and exit vi.
6. Active the new cron file with the command:
   
   crontab -u jimmo /tmp/crontab.jimmo

In this example, the job runs every ten minutes (*/10), but only from 8-17 (8 AM to 5 PM) and only on weekdays (day 1 to day 5)

What if you wanted it to run at these times, but only every three minutes? The line might look like this:

One really nice thing that a lot of Linux dialects do is allow you to specify abbreviations for the days of the week and the months. Its a lot easier to remember that fri is for Friday instead of 5.

With the exception of certain errors in the time fields, errors are not reported until cron runs the command. All error messages and output is mailed to the users. At least that’s what the crontab man-page says and that is basically true. However, as you see in the previous examples, you are redirecting stdout to /dev/null. If you wanted to, you could also redirect stderr there and you would never see whether there were any errors.

Output is mailed to the user because there is no real terminal on which the cronjobs are being executed. Therefore, there is no screen to display the errors. Also, there is no keyboard to accept input. Does that mean you cannot give input to a cron job? No. Think back to the discussion on shell scripts. We can redefine stdin, stdout and stderr. This way they can all point to files and behave as we expect.

Keep in mind that cron is not exact nor does it run in real-time. It synchronizes itself to the top of each minute. On a busy system in which you lose clock ticks, jobs may not be executed until a couple minutes after the scheduled time. In addition, there may be other processes with higher priorities that delay cron jobs. In some cases, (particularly on very busy systems) jobs might end up being skipped if they are run every minute.