A Unix system can have a lot to suffer from, but it usually suffers only during office hours. During the morning, the evening, the nights and weekends most Unix systems are just idling away (exept when they suffer from nerds). Using this idletime can be a lot cheaper than buying those machines you'd absolutely need if you want everything done at the same time.
There are three types of delayed execution:
Waiting a little while and then resuming job execution, this is done with the sleep command. Execution time depends on the system time at the moment of submission.
Run a command at a specified time, this is done using the at. Execution of the job(s) depends on system time, not on time of submission.
Regularly running a command: on a monthly, weekly, daily or hourly basis, using the cron facilities
We will discuss each command in the next sections.
The manpage of sleep is probably one of the shortest there is:
SLEEP(1) FSF SLEEP(1) NAME sleep - delay for a specified amount of time SYNOPSIS sleep [OPTION]... NUMBER[SUFFIX] DESCRIPTION Pause for NUMBER seconds. SUFFIX may be s to keep seconds, m for minutes, h for hours or d for days. --help display this help and exit --version output version information and exit AUTHOR Written by FIXME: unknown. REPORTING BUGS Report bugs to bug-sh-utilsatgnu.org COPYRIGHT Copyright © 1999 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. SEE ALSO The full documentation for sleep is maintained as a Texinfo manual. If the info and sleep programs are properly installed at your site, the command info sleep should give you access to the complete manual. GNU sh-utils 2.0 January 2001 1 (END)
And reading the info, it says the same. That's all sleep can do: wait.
So why does it exists? Some practical examples:
Somebody calls you on the phone, you say "Yes I'll be with you in half an hour" but your about drowned in work as it is and bound to forget your lunch:
(sleep 1800; echo "Lunch time..") &
When you can't use the at command for some reason, it's five o'clock, you want to go home but there's still work to do and right now somebody is eating system resources:
(sleep 10000; myprogram) &
Make sure there's an auto logout on your system, that you log out or that you lock your desktop/office when submitting this kind of job, or run it in screen.
When you run a series of printouts of large files, but you want other users to be able to print in between:
lp lotoftext; sleep 900; lp morelotoftext; sleep 900; lp anotherlargefile
The at command executes commands at a given time, using your default shell if you don't tell at otherwise (see the manpage).
The options to at are rather userfriendly, which is demonstrated in the examples below:
tille@sprawl:~>at tomorrow + 2 days warning: commands will be executed using (in order) a) $SHELL b) login shell c) /bin/sh at> cat maandreporten | mail myboss@mycompany at> <EOT> job 1 at 2001-06-16 12:36 tille@sprawl:~>at 0237 warning: commands will be executed using (in order) a) $SHELL b) login shell c) /bin/sh at> cd new-programs at> ./configure; make at> <EOT> job 2 at 2001-06-14 02:00
The -m option sends mail to the user when the job is done, or why a job can't be done. at -l lists jobs, perform this command before submitting at jobs in order not to let them start at the same time as others. With the atrm or -r option you can remove scheduled jobs if you change your mind.
It is a good idea to pick strange execution times, because you can't see all the other scheduled jobs (cronjobs, see next section) on the system. E.g. jobs are often run at 1 o'clock in the morning (e.g. system indexing to update a standard locate database), so entering a time of 100 may easily slow your system down rather than firing it up. To prevent jobs from running all at the same time, you may also use the batch command, which queues processes and feeds the work in the queue to the system in an evenly balanced way, preventing excessive bursts of use of system resources. See the manpages for more information.
The cron system is managed by the cron daemon. It gets information about which and when programs should run from the system's and users' crontab entries. Only the root user has access to the system crontabs, each user should only have access to his own crontabs. On some systems (some) users may not have access to the cron facility.
At system startup the daemon searches /var/spool/cron/ for crontab entries which are named after accounts in /etc/passwd, it searches /etc/cron.d/ and it searches etc/crontab. Then it uses this information every minute to check if there is something to be done. It executes commands as the user who owns the crontab file and mails any output of commands to the owner.
On systems using Vixie cron, jobs that occur hourly, daily, weekly and monthly are kept in separate directories in /etc to keep an overview.
Example of a crontab file:
[root@sprawl /etc]# more crontab SHELL=/bin/bash PATH=/sbin:/bin:/usr/sbin:/usr/bin MAILTO=root HOME=/ # run-parts # commands to execute every hour 01 * * * * root run-parts /etc/cron.hourly # commands to execute every day 02 4 * * * root run-parts /etc/cron.daily # commands to execute every week 22 4 * * 0 root run-parts /etc/cron.weekly commands to execute every month 42 4 1 * * root run-parts /etc/cron.monthly
Some variables are set, after that there's the actual scheduling, one line per job, starting with 5 time and date fields. The first field contains the minutes (from 0 to 59), the second defines the hour of execution (0-23), the third is day of the month (1-31), then the day of the month (1-12), the last is day of the week (0-7, both 0 and 7 are Sunday). An * in these fields represents the total acceptable range for the field. Lists are allowed, e.g. to execute a job from Monday to Friday enter 1-5 in the last field, to execute a job on Monday, Wednesday and Friday enter 1,3,5.
BSD systems specify an extra colum between these time and date fields and the last field, specifying the user who should run the command. This is because BSD based systems don't have a separate crontab file for each user.
The last field specifies the command to run. It is executed using the common shell (sh) unless otherwise defined.
Read your system specific documentation (man cron and man crontab (only for SysV cron implementations).