Classic Shell Scripting - Arnold Robbins [198]
The at command provides a simple way to run a program at a specified time. The syntax varies somewhat from system to system, but these examples give the general flavor:
at 21:00 < command-file
Run at 9 p.m.
at now < command-file
Run immediately
at now + 10 minutes < command-file
Run after 10 minutes
at now + 8 hours < command-file
Run after 8 hours
at 0400 tomorrow < command-file
Run at 4 a.m. tomorrow
at 14 July < command-file
Run next Bastille Day
at noon + 15 minutes < command-file
Run at 12:15 today
at teatime < command-file
Run this afternoon
In each case, the job to be run is defined by commands in command-file. at has somewhat eclectic ways of specifying time, as shown by the last example, which represents 16:00.
atq lists the jobs in the at queue and atrm removes them. For further details, consult the at manual pages on your system.
* * *
Tip
On some systems, the shell that is used to run the at commands is the Bourne shell (/bin/sh), and your login shell on other systems. You can insulate yourself from these variations by making the input to at a one-line command that names an executable script written in whatever language you find convenient, with the first line set to:
#! /path/to/script/interpreter
* * *
Whether the at family of commands is available to you depends on management policies. The files at.allow and at.deny control access: they are stored in /etc, /usr/lib/cron/at, /var/adm/cron, or /var/at, depending on the Unix flavor. If neither file exists, then only root can use at. If your system does not allow you to use the at commands, complain to your system manager: most sites should have little reason to forbid them.
batch: Delay for Resource Control
Historically, long before computers offered interactive access for humans, operating systems ran all processes in batch mode. A stream of jobs to be run is accumulated, and then processed in some order that might depend on the position of the job in the queue, who you are, how important you are, what resources you need and are permitted to have, how long you are prepared to wait, and how much you are willing to pay. Many mainframe computers and large compute servers still spend most of their CPU cycles this way.
All current Unix systems have a batch command that allow processes to be added to one of possibly several different batch queues. The syntax of batch varies from system to system, but all support reading commands from standard input:
batch < command-file
Run commands in batch
On some systems, this is equivalent to:
at -q b -m now < command-file
Run commands now under the batch queue
where -q b specifies the batch queue, -m requests mail to the user when the job completes, and now means that it is ready to run immediately.
The problem with batch is that it is too simplistic: it offers little control over batch processing order, and nothing in the way of batch policy. It is rarely needed on smaller systems. On larger ones, and especially on distributed systems, batch is replaced by much more sophisticated implementations, such as the ones shown in Table 13-2. Each of those packages has a collection of commands for submitting and managing batch jobs.
Table 13-2. Advanced batch queue and scheduler systems
Name
Web site
Generic Network Queueing System
http://www.gnqs.org/
IBM LoadLeveler
http://www.ibm.com/servers/eserver/pseries/library/sp_books/loadleveler.html
Maui Cluster Scheduler
http://supercluster.org/maui/
Platform LSF system
http://www.platform.com/products/LSFfamily/
Portable Batch System
http://www.openpbs.org/
Silver Grid Scheduler
http://supercluster.org/silver/
Sun GridEngine
http://gridengine.sunsource.net/
crontab: Rerun at Specified Times
Most computers have management tasks that need to be run repeatedly, such as filesystem backup every night, log-file and temporary-directory cleanup every week, account reporting once a month, and so on. Ordinary users may need such a facility