Chapter 25. Delayed Execution

25.1. Building Software Robots the Easy Way

If you are more familiar with desktop systems than Unix, the concept of delayed execution may be new to you. After all, the prime mover of all activity in the desktop metaphor is the user. In Unix, all kinds of processes start, execute, and report without any users on the system.

There are a few good reasons why you need to know about delayed execution. The first is that long, noninteractive jobs are best run when the fewest users are likely to be on the system. Humans find responsive systems desirable; processes aren't as likely to complain about getting sporadic CPU time. The second situation in which delayed execution is desirable is when a resource you need is only available at certain times. For instance, your group of local workstations create tar archives for the day's work, and you need to grab those files and copy them to tape. The third reason for delayed execution is when you need to push or pull information on a regular basis. This is the case with web masters who need to push their updated content to their production environment from their editing machine. The reverse may also hold true: you may need to collect Rich Site Summary files from a variety of web sites for a local cache. In all these cases, you need processes to start without you, like a band of relentless software robots.[79]

[79]Thanks to Jeff Sumler for the phrase "software robots."

This chapter covers the following techniques of delayed execution:

• The venerable cron (Section 25.2) system schedules process for regular, periodic execution. It is the most frequently used utility for running programs after hours.

• For processes that only need to run once at some future date, the at (Section 25.5) command is ideally suited.

• For simple scripts that need to pause before continuing on, the sleep (Section 25.9) command is available.

-- JJ