Typically, UNIX machines are left running all day and all night. UNIX offers several commands that let you take extra advantage of your existing computer resources. This chapter covers key concepts needed to schedule processes to run when you are not
present to start them manually. This chapter introduces the at command, which is used to schedule a command to run once later, and the cron command, which is used to schedule commands that need to be run regularly. Using these two commands can help you
manage your computer more effectively.
The at command is used to schedule a single command for execution at a later time. It is a tool that reads a series of commands from the standard input and schedules them for execution at a later time. Using at allows you to schedule system-intensive
jobs for off hours.
In its most basic form, you run at time and then type in a series of commands (followed by EOF) to be executed at the time you specify. The time can be one, two, or four digits (different versions of at support somewhat different time
specifications; check your online manual by typing man at or check your hardcopy manuals to learn more about your version of at). If you use one or two digits, the time is in hours. If you use four digits, the time is in minutes. The time is in twenty-four
hour clock time. The output of a job submitted to at is sent to you by electronic mail.
For example, to schedule a job to read the message of the day file and mail it to yourself at 5:30 p.m. today:
% # This example is from Solaris 2.3, which is SVR4 % at 1730 cat /etc/motd | mail myself <ctrl><d> warning: commands will be executed using /usr/bin/sh job 763169400.a at Tue Mar 8 17:30:00 1994 %
One important use of the at command is to schedule personal reminders. For example, if you have a meeting at 10:00 a.m. (and you run X11 and have the xmessage command), you might try the following command:
$ # This example is from HP-UX $ at 10 xmessage -display \fIhostname\fB:0.0 "You have a meeting!!!" <ctrl><d> job 763056000.a at Mon Mar 07 10:00:00 1994 $
This command schedules an at job that will run the xmessage program at 10 a.m. to display the message "You have a meeting!!!" on your X display.
Often, when you are using a computer, you will have large jobs that take up lots of computer time, memory, or do lots of input and output. You may want to run these jobs when you are away from your machine so that the machine won't be heavily loaded
when you need it for other tasks.
For example, if you want to run a large make that compiles many C files to build a tool you are working on, you might try:
$ #This example is from a BSD system $ cd make_directory $ at 1930 at> make -k all > /dev/null at> <ctrl><d> $
The batch command is very similar to the at command, with some useful differences. Rather than specify a time for your job to execute, the batch command schedules it to run as soon as possible with the restriction that only one or two batch jobs run at
a time. Jobs submitted with batch also run with a higher nice value so that they won't interfere with CPU usage. These two differences make batch a useful tool for scheduling large jobs that need to finish as soon as possible. The example of the make job
shown previously is easily modified to work with batch:
$ #This example is from a Solaris system $ cd make_directory; $ batch make -k all > /dev/null <ctrl><d> warning: commands will be executed using /usr/bin/sh job 763072415.b at Mon Mar 7 14:33:35 1994 at: this job may not be executed at the proper time. $
This job will run immediately and all error output will be mailed to you when it completes. Normal output is discarded.
The at and batch commands as they have been introduced are two different interfaces to a single job-queuing system on SYSV-based UNIX (and other versions of UNIX that have added these features). The queuing system is implemented in the SYSV cron program
(see "Chronologically Speakingcron" later in this chapter). There are 25 queues available: a, b, and d-z ("c" is used internally to implement crontab). By default, there are two queues that are implemented. Queue "a" is
used for jobs submitted by at; it allows a larger number of jobs (typically 4) to run with a small nice value (typically 1). Queue "b" is used for jobs submitted by batch; it allows a smaller number of jobs (typically 2) to run with a larger nice
value (typically 2).
On systems that use this version of cron, you may be able to add new queue levels by editing the queuedefs file (typically in /usr/lib/cron/queuedefs).
The template for a queuedefs entry is:
q is the queue designation: "a", "b" or c-z
job is the maximum number of simultaneous jobs
nice is the nice value for each job
nwait is the number of seconds to wait between attempts to reschedule a job delayed because of njob limits
A typical queuedefs file looks like the following:
a.4j1n b.2j2n90w m.1j10n600w
Queue "a" can have a maximum of four jobs running with nice value of one and a (default) reschedule delay of sixty seconds. Queue "b" can have a maximum of two jobs running with nice value of two and a reschedule delay of ninety
seconds. Queue "m" can have a maximum of one job running with nice value of ten and a reschedule delay of ten minutes.
Both the SYSV and BSD versions of at allow you to examine the list of jobs you have in the queues. The method of getting the list and the appearance of the output are slightly different.
On SYSV, you can list at jobs using at -l, which lists all jobs that you have in any of the at queues. For example, with several batch jobs submitted and a couple of jobs waiting to run in queue "m" (as specified in the example in the
preceding section, "Queue levels in at") and a single regular at job scheduled for 5:30 p.m., your output might look like the following:
$ date Wed Mar 9 15:13:56 CST 1994 $ at -l 763247633.m Wed Mar 09 15:13:53 1994 763255800.a Wed Mar 09 17:30:00 1994 763247641.m Wed Mar 09 15:14:01 1994 763247595.b Wed Mar 09 15:13:15 1994 763247599.b Wed Mar 09 15:13:19 1994 763247602.b Wed Mar 09 15:13:22 1994 $
On BSD, you can list at jobs using atq, which lists all jobs that you have in the single queue. With a single job scheduled, your output might look like the following:
$ at LAST EXECUTION TIME: Mar 9, 1994 at 15:00 Rank Execution Date Owner Job # Job Name 1st Mar 10, 1994 12:00 sartin 66588 stdin $
If you make a mistake or change your mind about running a job, you can remove it from the queue. If you didn't save the job ID that is printed by some versions of at when they add your job to the queue, you can get the job ID by listing at jobs and
removing the job. On SYSV, you remove the job using at -r jobid:
$ at -l 763250700.a Wed Mar 9 16:05:00 1994 $ at -r 763250700.a $ at -l $
On a BSD system, you remove the job using atrm jobid:
$ atq LAST EXECUTION TIME: Mar 9, 1994 at 15:00 Rank Execution Date Owner Job # Job Name 1st Mar 10, 1994 12:00 sartin 66588 stdin $ atrm 66588 66588: removed $ atq no files in queue. $
Although the at command is very useful for one-time jobs, it is somewhat difficult to use for scheduling repetitive tasks (see the note on using at to replace cron). UNIX also includes a program called cron that is responsible for running repetitively
scheduled jobs in a flexible fashion.
Historically, cron was introduced as a tool for system administrators and originally only allowed scheduling of tasks by "root" using a file /etc/crontab that the cron program would read for information on what jobs to run at what times. Since
that time, newer versions of cron have been introduced that allow individual users to have their own crontab, which specifies what jobs to run for that particular user.
When cron runs a job for you, it executes using your user ID and privileges, but with a more sparse environment. A job executed by cron will run with sh (usually the Bourne shell) in your home directory, but will not execute .profile. The environment
variables HOME, LOGNAME, PATH, and SHELL will be set. Your job should make minimal assumptions about its environment. For example, your PATH may only include /bin, /usr/bin and possibly your current working directory (which should be your home directory at
the start of the job).
The output of each job you run is saved and sent to you by electronic mail.
There are several different operations available from the crontab command that are used to view, modify, or remove your crontab. To see your current crontab, use crontab -l. This will list your current crontab on the standard output. For an example, see
To replace your crontab with a new crontab, use the command crontab new_crontab_file. This will replace your crontab completely, so make sure that new_crontab_file has any old crontab entries you want to keep. A good way to do this is to
use crontab -l first:
$ crontab -l > new_crontab_file $ vi new_crontab_file [edit the file to update your crontab] $ crontab new_crontab_file $
Some versions of crontab support a special option for editing and replacing your crontab. If your system supports this, you can edit your crontab by executing crontab -e.
To make it so that cron will not execute any jobs for you, you could execute crontab /dev/null, which would give you an empty crontab. A better way to do this is to execute crontab -r, which will remove your crontab completely.
A crontab has six fields:
day of month (1-31)
month of year (1-12)
day of week (0-6, 0 is Sunday)
Command (rest of line)
The first five fields are numeric patterns, which can be an asterisk (which means to use all legal values) or a list of elements. An element is either a single number or two numbers separated by a hyphen (which specifies an allowed range). Note that
both a day of month and day of week are specified. If both fields are used, they are both honored. For example:
0 17 1 * 0 date | mail user
will execute at 5 p.m. on the first of each month as well as at 5 p.m. on every Sunday.
Now look at Listing 20.1 in detail. Each line in the sample crontab illustrates a technique for using cron.
See LIST20_1 on the CD-ROM for a not-so-typical crontab.
Look at the line in Listing 20.1 that runs a program called hourly. Notice that both day fields, the month field, and the hour field are wild cards, whereas the minute field is "0." This means that the job will run on all days of all months at
all hours at 0 minutes into the hour. This job runs every hour on the hour.
Look at line 2 in Listing 20.1 that runs a program called quarter_hourly. Note the change. Note the use of a list in the minute field. The minute field is now a list of "0,15,30,45." This means that the job will run on all days of all months
at all hours at 0, 15, 30, and 45 minutes into the hour. This job runs every quarter hour.
The business_hourly script runs every hour during business hours. Note the use of ranges in the hour field (to limit the job to run between 8 a.m. and 6 p.m.) and the day of week field (to limit the job to run Monday through Friday).
Look at the line in Listing 20.1 that runs a program called daily. Notice that both day fields and the month field are wild cards, whereas the hour field is "8" and the minute field is "0." This means that the job will run every day
at 8 a.m. The weekly script will run every Monday at 8 a.m. The monthly script will run just after midnight on the morning of the first of each month.
The two executions of the birthday script will each run once per year, one on April 20, with the argument rachel, and one on October 7, with the argument rob.
See Listing 20.2 for an example of a Korn shell script intended to be run as a cron job. This script sends a status summary based on the contents of two files in ~/status: a file named todo, which is a "to do" list, and a file named done,
which is a list of tasks completed. During the week, you can move items from the todo file to the done. At the end of the week, this script can be run from cron and it will mail a weekly summary, add your done items to the file log, and mail a summary to
you. Note that the script redirects all expected output either to a file or to the mail_command. Note that it tries to configure using only the environment variables LOGNAME and HOME. It uses only standard commands that are available in the default
Here is a cron entry to run this script every Monday morning at 8:00:
0 8 * * /u/sartin/bin/status_report
See LIST 20_2 on the CD-ROM for a sample cron script.
As a system administrator, you will either control cron and at access using cron.allow or cron.deny and at.allow and at.deny (Check your system's documentation to determine the locations of these files. They are typically in /usr/spool/cron or
/var/spool/cron.) You will need to make a basic policy decision on whether users should be granted access to these tools. One possible policy is that all users are granted access and are denied access only if they abuse the facility; in this case, use the
cron.deny file to list those users who should not use cron, and at.deny to list those who should not use at. Another possible policy is that users must request permission to use these tools; in this case, use cron.allow and at.allow to list users who have
been granted permission.
You should use one or more crontabs to schedule all of your repetitive administrative tasks, such as backups, log file administration, news expiration, and file archival. See Listing 20.3 for a sample script that does simple log file pruning. Run this
from your crontab as prunelog path_to_log_file .... It will keep the 10 most recent days (or weeks or hours) of log files available for review, and throw out older data to prevent running out of disk space.
If your system uses a cron like the SYSV one, you should take advantage of the user-specific crontabs to split administrative tasks. For example, all Usenet cron jobs should be in the crontab for user netnews (or whatever user ID you use for the news
software). Only those jobs that need "root" privileges should be in the crontab for "root."
Here is a crontab entry that will execute this job to prune /usr/spool/mqueue/syslog:
0 1 * * * /usr/adm/prunelog /usr/spool/mqueue/syslog
See LIST20_3 on the CD-ROM for a program that prunes log delete files with cron.
In this chapter, you have learned how to use at to schedule one-time jobs; how to use batch (and at -q) to run large jobs without loading your system badly; and how to use cron to schedule recurring jobs. These techniques should help you to get maximum
benefit out of your computer even when you are not around to use it.