The crontab fileconsists of a
series of entries specifying what command to run and when to run
it. It is also possible to document crontab entries with
comments. Anything on a line after a pound sign (#) is considered
a comment and will be ignored. Placing a pound sign in front of a
crontab entry can temporarily disable it. Blank lines in the
crontab file are completely ignored.
Crontab Entries
Each crontab entryline is
comprised of six positional fields specifying the time, date and
the command to be run. The format of a crontab entry is described
in the table below:
|
Field |
Minute |
Hour |
Day of Month |
Month |
Day of Week |
Command |
|
Valid values |
0-59 |
0-23 |
1-31 |
1-12 |
0-7 |
Command path/command |
Table 9.2: Format of a crontab Entry
Note: Unlike with
many UNIX operating systems, in Linux either 0 or 7 is
acceptable to indicate Sunday in the 'day of week' field.
|
Each of these fields can contain a single number, a range of
numbers indicated with a hyphen (such as 2-4), a list of specific
values separated by commas (like 2,3,4) or a combination of these
designations separated by commas (such as 1,3-5). Any of these
fields may also contain an asterisk (*) indicating every possible
value of this field. This can all get rather confusing, so take a
look at a few examples.
# Daily
full export
00 01 * * * /u01/app/oracle/admin/test/scripts/full_export.sh
This entry will run the full_export.sh script at 0
minutes past 1 am, every day of the month, every month of the year
and every day of the week. As with scripts and other
configuration files, comments help make the crontab file more
readable.
# Weekly
full hot backup
00 03 * * 0 /u01/app/oracle/admin/common/scripts/hot_backup.sh
oss 0
This entry runs at 3:00 am, but only on Sundays (day 0.). While
the day of month and month fields have asterisks, this entry will
only be run on Sundays since crontab entries will only be executed
when all the given values are met.
# Nightly
incremental hot backup
00 03 * * 1-6 /u01/app/oracle/admin/common/scripts/hot_backup.sh
oss 1
In this entry, it has been specified that the script
should be run at 3:00 a.m. Monday through Saturday.
00,15,30,45 * *
* * /u01/app/oracle/admin/common/scripts/check_disk_space.sh
This entry has minutes separated by a comma indicating that it
should be run at each of the indicated times. Since all the other
fields are wildcards (*), the entry is run on the hour (00), 15
minutes past the hour, 30 minutes past the hour and 45 minutes
past the hour for every hour of the day and every day of the year.
00 12 * * 1-5
/home/oracle/lunch_time.sh
This lunch reminder is set up to run at 12:00 p.m. Monday
through Friday only.
The most important thing to remember is that a crontab entry
will execute every time all of its conditions are met. To take
the last entry as an example, any time it is 00 minutes past the
hour of 12 on any day of the month and any month of the year and
the day of the week is between Monday and Friday inclusive (1-5),
this crontab will be executed.
Wildcards are used in most crontab entries, but be careful
where they are used. For instance, if a * is mistakenly placed in
the minute position of the last crontab example above, the script
would end up being run for every minute of the 12:00 hour instead
of just once at the beginning of the hour. I do not think anyone
needs that many reminders to go to lunch, do they?
Quite a bit of this chapter has been about how to specify the
date and time in the crontab, but what about the command? Well,
most folks will write shell scripts to execute with their crontab
entries, but you can actually just execute a command from the
crontab as well. Either way, be sure the absolute pathto the command is placed in the crontab.
When a script or command is run from a user's crontab, the
user's environment files (.bash_profile and the like) are not
run. If scripts and commands are dependent on environment
variables, i.e. SQL*Plus can rely on the ORACLE_SID variable,
those variables need to be set as part of a script.
If the command or script you call in your crontab sends output
to the screen, some systems will attempt to email the output to
the owner of the crontab file. This can be useful, but where is
that email going? If you are checking the account regularly or
forwarding the email to another account, this may be sufficient;
but as will be seen in the shell scripting section, it may be much
better to create a custom email within the script and handle any
output that way.
Another option is to redirect that output to a log file with
the >> symbol so it can be checked later. Be careful with this as
the log files may get rather large over time!
