Periodic Tasks
CRON: SCHEDULE COMMANDS
Under Linux, periodic execution is normally handled by the cron daemon. cron starts when the system boots and remains running as long as the system is up. cron reads one or more configuration files containing lists of command lines and times at which they are to be invoked. The command lines are executed by sh, so almost anything you can do by hand from the shell can also be done with cron.
A cron configuration file is called a “crontab,” short for “cron table.” cron looks for crontab files in three places: /var/spool/cron (/var/spool/cron/tabs on SUSE and /var/spool/cron/crontabs on Debian), /etc/cron.d, and /etc/crontab.
Crontab files for individual users are stored underneath /var/spool/cron. Typically, there is (at most) one crontab file per user: one for root, one for jsmith, and so on. Crontab files are named with the login names of the users they belong to, and cron uses these filenames to figure out which UID to use when running the commands that each file contains. The crontab command transfers crontab files to and from this directory.
Crontab files that schedule system maintenance tasks and other tasks defined by the system administrator are stored in the file /etc/crontab and in other files found in the /etc/cron.d directory. These files have a slightly different format from the per-user crontab files because they allow commands to be run as an arbitrary user. cron treats the /etc/crontab and /etc/cron.d entries in exactly the same way. In general, /etc/crontab is intended as a file for the system administrator to maintain by hand, whereas /etc/cron.d is provided as a place where software packages can install any crontab entries they might need.
When cron starts, it reads all of its config files, stores them in memory, and then goes to sleep. Once each minute, cron wakes up, checks the modification times on the crontab files, reloads any files that have changed, and then executes any tasks scheduled for that minute before returning to sleep.
THE FORMAT OF CRONTAB FILES
All the crontab files on a system share a similar format. Comments are introduced with a pound sign (#) in the first column of a line. Each noncomment line contains six or seven fields and represents one command:
minute hour day month weekday [username] command or
minute hour day month weekday [username] run-parts directory
The first six fields are separated by whitespace, but within the command field whitespace is taken literally. The username is found only in /etc/crontab and in files from the /etc/cron.d directory; it specifies on whose behalf the command should be run. This field is not present or necessary in the user-specific crontab files (those stored in /var/spool/cron) because the UID is implied by the filename.
The minute, hour, day, month and weekday fields tell when to run the command.
Their interpretations are shown below:
Each of the time-related fields may contain:
There is a potential ambiguity to watch out for with the weekday and day fields. Every day is both a day of the week and a day of the month. If both weekday and day are specified, a day need satisfy only one of the two conditions in order to be selected.
The command is the sh command line to be executed. It can be any valid shell command and should not be quoted. command is considered to continue to the end of the line and may contain blanks or tabs.
Eg. 20 1 * * * find /tmp -atime +3 -exec rm -f { } ';'
This command will run at 1:20 each morning. It removes all files in the /tmp directory that have not been accessed in 3 days.
CRONTAB MANAGEMENT
crontab filename installs filename as your crontab, replacing any previous version. crontab -e checks out a copy of your crontab, invokes your editor on it (as specified by the EDITOR environment variable), and then resubmits it to the crontab directory. crontab -l lists the contents of your crontab to standard output, and crontab -r removes it, leaving you with no crontab file at all.
Root can supply a username argument to edit or view other users' crontabs. For example, crontab -u jsmith -r erases the crontab belonging to the user jsmith.
Two config files, /etc/cron.deny and /etc/cron.allow, specify which users may submit crontab files. If the allow file exists, then it contains a list of all users that may submit crontabs, one per line. No unlisted person can invoke the crontab command. If the allow file doesn’t exist, then the deny file is checked. It, too, is just a list of users, but the meaning is reversed: everyone except the listed users is allowed access. If neither the allow file nor the deny file exists, most systems allow only root to submit crontabs. (Debian and Ubuntu default to allowing submissions by all users.)
Under Linux, periodic execution is normally handled by the cron daemon. cron starts when the system boots and remains running as long as the system is up. cron reads one or more configuration files containing lists of command lines and times at which they are to be invoked. The command lines are executed by sh, so almost anything you can do by hand from the shell can also be done with cron.
A cron configuration file is called a “crontab,” short for “cron table.” cron looks for crontab files in three places: /var/spool/cron (/var/spool/cron/tabs on SUSE and /var/spool/cron/crontabs on Debian), /etc/cron.d, and /etc/crontab.
Crontab files for individual users are stored underneath /var/spool/cron. Typically, there is (at most) one crontab file per user: one for root, one for jsmith, and so on. Crontab files are named with the login names of the users they belong to, and cron uses these filenames to figure out which UID to use when running the commands that each file contains. The crontab command transfers crontab files to and from this directory.
Crontab files that schedule system maintenance tasks and other tasks defined by the system administrator are stored in the file /etc/crontab and in other files found in the /etc/cron.d directory. These files have a slightly different format from the per-user crontab files because they allow commands to be run as an arbitrary user. cron treats the /etc/crontab and /etc/cron.d entries in exactly the same way. In general, /etc/crontab is intended as a file for the system administrator to maintain by hand, whereas /etc/cron.d is provided as a place where software packages can install any crontab entries they might need.
When cron starts, it reads all of its config files, stores them in memory, and then goes to sleep. Once each minute, cron wakes up, checks the modification times on the crontab files, reloads any files that have changed, and then executes any tasks scheduled for that minute before returning to sleep.
THE FORMAT OF CRONTAB FILES
All the crontab files on a system share a similar format. Comments are introduced with a pound sign (#) in the first column of a line. Each noncomment line contains six or seven fields and represents one command:
minute hour day month weekday [username] command or
minute hour day month weekday [username] run-parts directory
The first six fields are separated by whitespace, but within the command field whitespace is taken literally. The username is found only in /etc/crontab and in files from the /etc/cron.d directory; it specifies on whose behalf the command should be run. This field is not present or necessary in the user-specific crontab files (those stored in /var/spool/cron) because the UID is implied by the filename.
The minute, hour, day, month and weekday fields tell when to run the command.
Their interpretations are shown below:
| Field | Description | Range |
| Minute | Minute of the hour | 0 to 59 |
| Hour | Hour of the day | 0 to 23 |
| Day | Day of the month | 1 to 31 |
| Month | Month of the year | 1 to 12 |
| WeekDay | Day of the week | 0 to 6 (0=sunday) |
Each of the time-related fields may contain:
- A star, which matches everything
- A single integer, which matches exactly
- Two integers separated by a dash, matching a range of values
- A comma-separated series of integers or ranges, matching any listed value
There is a potential ambiguity to watch out for with the weekday and day fields. Every day is both a day of the week and a day of the month. If both weekday and day are specified, a day need satisfy only one of the two conditions in order to be selected.
The command is the sh command line to be executed. It can be any valid shell command and should not be quoted. command is considered to continue to the end of the line and may contain blanks or tabs.
Eg. 20 1 * * * find /tmp -atime +3 -exec rm -f { } ';'
This command will run at 1:20 each morning. It removes all files in the /tmp directory that have not been accessed in 3 days.
CRONTAB MANAGEMENT
crontab filename installs filename as your crontab, replacing any previous version. crontab -e checks out a copy of your crontab, invokes your editor on it (as specified by the EDITOR environment variable), and then resubmits it to the crontab directory. crontab -l lists the contents of your crontab to standard output, and crontab -r removes it, leaving you with no crontab file at all.
Root can supply a username argument to edit or view other users' crontabs. For example, crontab -u jsmith -r erases the crontab belonging to the user jsmith.
Two config files, /etc/cron.deny and /etc/cron.allow, specify which users may submit crontab files. If the allow file exists, then it contains a list of all users that may submit crontabs, one per line. No unlisted person can invoke the crontab command. If the allow file doesn’t exist, then the deny file is checked. It, too, is just a list of users, but the meaning is reversed: everyone except the listed users is allowed access. If neither the allow file nor the deny file exists, most systems allow only root to submit crontabs. (Debian and Ubuntu default to allowing submissions by all users.)