4.4. Scheduling processes
4.4.1. Use that idle time!
A Linux system can have a lot to suffer from, but it usually suffers only during office hours. Whether in an office environment, a server room or at home, most Linux systems are just idling away during the morning, the evening, the nights and weekends. Using this idle time 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, using the sleep command. Execution time depends on the system time at the moment of submission.
Running a command at a specified time, using the at command. Execution of the job(s) depends on system time, not the time of submission.
Regularly running a command on a monthly, weekly, daily or hourly basis, using the cron facilities.
The following sections discuss each possibility.
4.4.2. The sleep command
The Info page on sleep is probably one of the shortest there is. All sleep does is wait. By default the time to wait is expressed in seconds.
So why does it exist? Some practical examples:
Somebody calls you on the phone, you say "Yes I'll be with you in half an hour" but you're 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, and that you log out or lock your desktop/office when submitting this kind of job, or run it in a screen session.
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 hugefile; sleep 900; lp anotherlargefile
Printing files is discussed in Chapter 8.
Programmers often use the sleep command to halt script or program execution for a certain time.
4.4.3. The at command
The at command executes commands at a given time, using your default shell unless you tell the command otherwise (see the man page).
The options to at are rather user-friendly, which is demonstrated in the examples below:
steven@home:~> at tomorrow + 2 days
warning: commands will be executed using (in order) a) $SHELL
b) login shell c) /bin/sh
at> cat reports | mail myboss@mycompany
at> <EOT>
job 1 at 2001-06-16 12:36
|
Typing Ctrl+D quits the at utility and generates the "EOT" message.
User steven does a strange thing here combining two commands; we will study this sort of practice in Chapter 5, Redirecting Input and Output.
steven@home:~> 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 explains when a job can't be done. The command atq lists jobs; perform this command before submitting jobs in order prevent them from starting at the same time as others. With the atrm command you can remove scheduled jobs if you change your mind.
It is a good idea to pick strange execution times, because system jobs are often run at "round" hours, as you can see in Section 4.4.4 the next section. For example, jobs are often run at exactly 1 o'clock in the morning (e.g. system indexing to update a standard locate database), so entering a time of 0100 may easily slow your system down rather than fire 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 system resource usage. See the Info pages for more information.
4.4.4. Cron and crontab
The cron system is managed by the cron daemon. It gets information about which programs and when they should run from the system's and users' crontab entries. Only the root user has access to the system crontabs, while 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 cron 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 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, as opposed to the standard UNIX cron function, where all tasks are entered into one big file.
Example of a Vixie crontab file:
[root@blob /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, and 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 number of the month (1-12), the last is day of the week (0-7, both 0 and 7 are Sunday). An asterisk in these fields represents the total acceptable range for the field. Lists are allowed; 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.
Then comes the user who should run the processes which are listed in the last column. The example above is from a Vixie cron configuration where root runs the program run-parts on regular intervals, with the appropriate directories as options. In these directories, the actual jobs to be executed at the scheduled time are stored as shell scripts, like this little script that is run daily to update the database used by the locate command:
billy@ahost cron.daily]$ cat slocate.cron #!/bin/sh renice +19 -p $$ >/dev/null 2>&1 /usr/bin/updatedb -f "nfs,smbfs,ncpfs,proc,devpts" -e \ "/tmp,/var/tmp, /usr/tmp,/afs,/net" |
Users are supposed to edit their crontabs in a safe way using the crontab -e command. This will prevent a user from accidentally opening more than one copy of his/her crontab file. The default editor is vi (see Chapter 6, but you can use any text editor, such as gvim or gedit if you feel more comfortable with a GUI editor.
When you quit, the system will tell you that a new crontab is installed.
This crontab entry reminds billy to go to his sports club every Thursday night:
billy:~> crontab -l # DO NOT EDIT THIS FILE - edit the master and reinstall. # (/tmp/crontab.20264 installed on Sun Jul 20 22:35:14 2003) # (Cron version -- $Id: chap4.xml,v 1.16 2004/07/09 05:34:22 tille Exp $) 38 16 * * 3 mail -s "sports evening" billy |
After adding a new scheduled task, the system will tell you that a new crontab is installed. You do not need to restart the crond daemon for the changes to take effect. In the example, billy added a new line pointing to a backup script:
billy:~> crontab -e 45 15 * * 3 mail -s "sports evening" billy 4 4 * * 4,7 /home/billy/bin/backup.sh <--write and quit--> crontab: installing new crontab billy:~> |
The backup.sh script is executed every Thursday and Sunday. See Section 7.2.5 for an introduction to shell scripting. Keep in mind that output of commands, if any, is mailed to the owner of the crontab file. If no mail service is configured, you might find the output of your commands in your local mailbox, /var/spool/mail/<your_username>, a plain text file.
 | Who runs my commands? |
|---|---|
You don't have to specify the user who should run the commands. They are executed with the user's own permissions by default. |
