Scheduled Activity: cron and at
The Linux utilities cron and at are related commands. The cron utility allows you to schedule a repetitive task to take place at any regular interval desired, and the at command lets you specify a one-time action to take place at some desired time. You might use crontab, for example, to perform a backup each morning at 2 a.m., and use at to remind yourself of an appointment later in the day.
The word “crontab” is a Unixism for “chron table”, or time table. You create a table in the required format, specifying commands and times to execute the commands. Commands you put in the table can be any executable programs—for example, a command in /usr/bin or a shell script you wrote. You use the crontab command to create, edit, or list the table, and the system cron daemon reads the table and executes the commands at the times specified.
The cron daemon is normally executed at system startup and does not exit. On my Linux system, the cron daemon is actually Matthew Dillon's crond, and is started in /etc/rc.d/rc.M with the following line:
/usr/sbin/crond -l10 >/var/adm/cron 2>&1
On some Linux systems, Paul Vixie's cron daemon is used, in which case the name of the daemon is simply cron. Also, on systems with newer versions of init, cron is started from the /etc/init.d/cron script.
You can check to see if a cron daemon is running on your system with a command such as the following:
$ ps -ax | grep cron raithel 733 pp0 S 0:00 grep cron root 25 ? S 0:00 /usr/sbin/crond -l10
In this case, we see that the crond daemon is indeed running.
When the cron daemon starts, it reads the various crontab tables in the crontab directory, normally /usr/spool/cron/crontabs. To create or change your crontab file, use crontab's -e option:
$ crontab -e
You are placed in a text editor with a copy of your current crontab file, if it exists, or a blank file, if it does not. The text editor you get is determined by the setting of your VISUAL environment variable (or EDITOR, if VISUAL is not set) and is usually the vi editor, if you have not specified otherwise.
To schedule commands with crontab, you must use the format cron recognizes in a crontab file. The format is not exactly mnemonic, so I create a crontab file with a header commented out that provides the necessary information:
# minute (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), # command
Each crontab entry is a single line composed of these six fields, separated by white space. Specify the minute a command is to be executed with the digits 0 through 59 in the first field, the hour with 0 through 23 in the second field, the day of the month with 1 through 31 in the third field, the month of the year with 1 through 12 in the fourth field, and the day of the week with 0 through 6 in the fifth field. Place the command to be executed in the sixth field.
At first glance it may appear that redundant or conflicting information is required because there are two “day” fields—day of the month and day of the week, but this is really just to permit different scheduling algorithms. For instance, you may want to be reminded to attend a meeting every Tuesday or to pick up your paycheck every 15th of the month. Enter an asterisk (*) in the day field you are not using. You can use both day fields if you prefer to have the command execute on, say, the fifteenth of the month as well as every Tuesday.
Ranges are specified with a dash. If you want to specify the eighth through the fifteenth days of the month, enter 8-15 in the third field. Non-consecutive entries in a field are separated by commas, so 1,15 in the third field means the first and fifteenth of the month. To specify all values for a field, for example every month of the year, enter an asterisk (*) in the field. (Note that to specify every day you must enter * in both day fields.)
Here is an example crontab file with two entries:
# minute (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) # command 12 4 * * * /usr/local/bin/backup 5 3 10-15 4 * echo "taxes due" | mail jones
The first line after the comments causes a backup script to execute early each morning at 4:12 a.m., and the second line causes the user jones to get a mail message for six days in April as a reminder that taxes are due. In general, it's a good idea to execute crontab commands at off hours like these to reduce any effect on system load during normal usage hours.
If you don't specifically redirect standard error and standard output, they are mailed to you as owner of the crontab file when the command executes. In the example above, if the user jones cannot be found, you would be mailed the output as well as an error message.
After editing the crontab file, save it and exit from the editor. A file is created for you in the crontab directory. For example, the crontab for root is the file /usr/spool/cron/crontabs/root. This file is read by the system cron daemon and stored in an internal format, where it will remain to be periodically executed until it is changed or deleted.
To view your current crontab file, use the -l (for “list”) option:
$ crontab -l
To delete your file, use:
$ crontab -d
If you are superuser, you can delete any user's crontab file with:
# crontab -d username
where username is the user's login name.
The crontab commands discussed above work fine on my Linux system and should work on System V and BSD Unix systems, as well. One thing to be aware of when using crontab on other systems or moving crontab files to other systems is that some cron daemons allow the superuser to restrict crontab service by the creation of cron.allow and cron.deny files. Refer to the specific system documentation for details.
Also, most versions of cron provide an /etc/crontab file which has an extra field in it—the user as which to execute the command. Again, check the documentation for your version of cron for more details.
|PostgreSQL, the NoSQL Database||Jan 29, 2015|
|HPC Cluster Grant Accepting Applications!||Jan 28, 2015|
|Sharing Admin Privileges for Many Hosts Securely||Jan 28, 2015|
|Red Hat Enterprise Linux 7.1 beta available on IBM Power Platform||Jan 23, 2015|
|Designing with Linux||Jan 22, 2015|
|Wondershaper—QOS in a Pinch||Jan 21, 2015|
- PostgreSQL, the NoSQL Database
- Sharing Admin Privileges for Many Hosts Securely
- HPC Cluster Grant Accepting Applications!
- Internet of Things Blows Away CES, and it May Be Hunting for YOU Next
- Ideal Backups with zbackup
- Wondershaper—QOS in a Pinch
- Red Hat Enterprise Linux 7.1 beta available on IBM Power Platform
- Designing with Linux
- Slow System? iotop Is Your Friend
- January 2015 Issue of Linux Journal: Security
Editorial Advisory Panel
Thank you to our 2014 Editorial Advisors!
- Jeff Parent
- Brad Baillio
- Nick Baronian
- Steve Case
- Chadalavada Kalyana
- Caleb Cullen
- Keir Davis
- Michael Eager
- Nick Faltys
- Dennis Frey
- Philip Jacob
- Jay Kruizenga
- Steve Marquez
- Dave McAllister
- Craig Oda
- Mike Roberts
- Chris Stark
- Patrick Swartz
- David Lynch
- Alicia Gibb
- Thomas Quinlan
- Carson McDonald
- Kristen Shoemaker
- Charnell Luchich
- James Walker
- Victor Gregorio
- Hari Boukis
- Brian Conner
- David Lane