Scheduling tasks is as old as Unix. Usually, it is a concern for root users, handy for making sure that jobs like backups are done regularly. However, scheduling can also be useful for regular users, if only to broadcast a message to themselves to take a break. Either way, you have three scheduling systems for your needs: at [1] and its related commands, cron [2], and anacron [3]. The three overlap, but each has its own peculiarities for configuration and scheduling.

The at Family of Commands

At and its associated commands are for scheduling of a one-time event. By default, the commands can only be run by root. However, other users can also be permitted to run at if you create a file called /etc/at.allow, adding names one per line. You can also add users to /etc/at.deny if there are users whom you specifically do not want to use the commands, including users that exist for administrative purposes or users that might be created by intruders, such as guest (Figure 1).

Figure 1: /etc/at.deny specifies users who are not permitted to use at. A companion file, /etc/at.allow, can also be created.

To schedule a command to run once, enter the command followed by a time. The time must be precise down to minutes and can be precise down to seconds using the MMDDhhmm[.ss] format. You can also specify the fixed times midnight, noon, or teatime (4pm) or a specific date followed by the time. Similarly, you can specify now, today, or tomorrow, optionally adding a time after now or today. For instance, 5pm + 1 week or noon August 2 would both be valid time entries. Should you enter a time that has already passed, such as 11am today when it is 4pm, the command will be run in about five minutes.

No matter how you enter the time, running the command will start the at command prompt. Enter as many commands as you want at the prompt, and press Ctrl+D when you are finished (Figure 2). A message is sent to the user, who receives mail from root.

Figure 2: A successful command entered into at.

at itself has a limited set of options. You can suppress mail with -m or run a list of commands in a file using -f FILE. There are also aliases for the related commands, but most users will probably find it easier to remember the full names of the commands. Here they are with examples:

• atq: Lists scheduled jobs. If used by root, everybody's jobs are listed (Figure 3).

Figure 3: Atq lists scheduled jobs.

• atrm: Removes scheduled jobs, using their job number. No confirmation dialog appears, so check job numbers using atq first.
• batch: Used instead of at to run commands when the system load levels permit. Batch accepts no time parameters, since they are irrelevant. Up to 52 batches can be set at one time. The names for batches begin with lowercase a, and end with uppercase Z.

Should you have trouble running the at family of commands, run service atd status. If at is not running, you can start it with service atd start.

Running cron Jobs

The main difference between at and cron is that at is for a command to be scheduled once, and cron is for a command to be used repeatedly. In addition, a cron entry requires more information than an at entry.

Like at, the use of cron is controlled by two files – in cron's case, /etc/cron.deny and /etc/cron.allow. Both the cron commands must be created using touch before any user except root can use cron. As with at's files, cron's files list users one per line. For added security, you may want to copy the contents of at.deny into cron.deny.

cron jobs to be run are stored in a file called a crontab. Non-root users can be given their own crontab by running crontab -u USER FILE, most likely using ~/.crontab.

To add a cron job, run crontab -e to manually enter a task. The first time a user runs crontab, they are asked to select a default editor to use (Figure 4) from among those installed on the system. They can then enter a cron job, one per line (Figure 5). Root's crontab is commented, while other users' are not – presumably because non-root users are rare.

Figure 4: The first time you run crontab, you are asked to choose an editor.

Figure 5: Root's crontab includes helpful comments.

A cron job has five fields:

MINUTES(0-59) HOURS(0-23)
  DAY-OF-THE-MONTH(1-31)
  MONTH(1-12) DAY-OF-THE-WEEK(0-6)
  COMMAND

Notice that the numbering is inconsistent: While days and months have the expected range of numbers, minutes, hours, days of the week begin at 0 instead of 1. There is no particular reason for this inconsistency except an outbreak of geekiness.

For example:

sends a message to all users about upcoming maintenance at 12:45 on Wednesday, May 13.

The first five fields do not have to be all filled out, so long as those that have an entry produce a legitimate date. For example, the day of the week, the fifth column could be left blank except for an asterisk so that the command would run on any May 13, no matter what the day of the week. In addition, each of the first five fields can be filled by a comma-separated list of entries. If you want to run a job at a regular interval, you can add an interval divided by 10 to the minutes field (for instance, */20).

You can see a list of jobs by running cronjob -l and remove the entire file with cronjob -r.

All commands are written by default to /var/spool/cron/crontabs, with separate entries or crontabs for each authorized user. cron also reads /etc/crontab, /etc/cron.daily, /etc/cron.weekly, and /etc/cron.monthly (which may have to be created). These directories consist simply of shell scripts that run 15 minutes after boot time or set in /etc/sysconfig/cron file.

However, these entries in -etc subdirectories are actually a redundancy, because the root user can get the same scheduling by selecting the fields to fill in the normal crontab. It can be confusing to use two different forms of scheduling, and the trend in recent years is not to use them at all. Instead, users can replace the five traditional fields of a cron job with the notations in Table 1.

Off and On with anacron

cron was designed for systems that are always running, such as servers. By contrast, anacron has the flexibility to run on machines that are frequently turned off and on, such as personal laptops and workstations. If a system is not turned on when an anacron job is scheduled, it simply runs the next time the system is booted.

Another difference between cron and anacron is that anacron's jobs are stored in the file/etc/anacronjob. Jobs are added to anacronjob using a text editor. One job is defined per line, in the following format:

PERIOD(DAYS) DELAY(MINUTES) ID COMMAND

PERIOD is the number of days between each running of the command or else one of these tags: @daily, @weekly, or @monthly. The period works with the DELAY field, or the number of minutes after bootup that the job is run. Probably, you will want to run anacron jobs at least ten minutes after bootup, just to assure that no other commands are run at the same time from login scripts. Otherwise, no more precise timing is available, and when a command runs is relative to the boot time, not an absolute time by the calendar and clock, as with cron. The ID is the name of the command or script to run, the command, the actual path, and structure of the file. For instance,

runs the trim command for SSD drives once a week 10 minutes after bootup.

You can view scheduled anacron tasks with the command ls -l /var/spool/anacron/(Figure 6). Tasks scheduled daily, weekly, or monthly will be marked.

Figure 6: Use the ls command to view scheduled anacron jobs.

anacron is not set up with everyday users in mind. However, you can specify another anacrontab using -t $~/etc/anacrontab to specify a personal list of jobs, and -S $~/var/spool/anacron for a personal spool in your ~/.profile.