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.
Special Reports: DevOps
Have projects in development that need help? Have a great development operation in place that can ALWAYS be better? Regardless of where you are in your DevOps process, Linux Journal can help!
With deep focus on Collaborative Development, Continuous Testing and Release & Deployment, we offer here the DEFINITIVE DevOps for Dummies, a mobile Application Development Primer, advice & help from the experts, plus a host of other books, videos, podcasts and more. All free with a quick, one-time registration. Start browsing now...
- Hash Tables—Theory and Practice
- The Ubuntu Conspiracy
- A First Look at IBM's New Linux Servers
- Vigilante Malware
- Making a PHP Site on Linux Work with a Microsoft SQL Server Database
- Disney's Linux Light Bulbs (Not a "Luxo Jr." Reboot)
- Vagrant Simplified
- Science on Android
- System Status as SMS Text Messages
- Bluetooth Hacks