Scheduled Activity: cron and at

Your Linux computer can be made to do the right thing at the right time.

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.

Using crontab

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

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.

The crontab Table

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.

______________________

White Paper
Linux Management with Red Hat Satellite: Measuring Business Impact and ROI

Linux has become a key foundation for supporting today's rapidly growing IT environments. Linux is being used to deploy business applications and databases, trading on its reputation as a low-cost operating environment. For many IT organizations, Linux is a mainstay for deploying Web servers and has evolved from handling basic file, print, and utility workloads to running mission-critical applications and databases, physically, virtually, and in the cloud. As Linux grows in importance in terms of value to the business, managing Linux environments to high standards of service quality — availability, security, and performance — becomes an essential requirement for business success.

Learn More

Sponsored by Red Hat

White Paper
Private PaaS for the Agile Enterprise

If you already use virtualized infrastructure, you are well on your way to leveraging the power of the cloud. Virtualization offers the promise of limitless resources, but how do you manage that scalability when your DevOps team doesn’t scale? In today’s hypercompetitive markets, fast results can make a difference between leading the pack vs. obsolescence. Organizations need more benefits from cloud computing than just raw resources. They need agility, flexibility, convenience, ROI, and control.

Stackato private Platform-as-a-Service technology from ActiveState extends your private cloud infrastructure by creating a private PaaS to provide on-demand availability, flexibility, control, and ultimately, faster time-to-market for your enterprise.

Learn More

Sponsored by ActiveState