18.4. Objective 4: Automate System Administration Tasks by Scheduling Jobs to Run in the Future There is a surprising amount of housekeeping that must be done to keep a complex operating system such as Linux running smoothly. Log file rotation, cleanup of temporary files and directories, system database rebuilds, backups, and other tasks should be done routinely. Clearly such mundane things should be automated by the system, freeing weary system administrators for more interesting work. Fortunately, any system task that can be accomplished without real-time human intervention can be automated on Linux using the cron and at facilities. Both have the ability to execute system commands, which may start any executable program or script, at selectable times. Further, cron and at can execute these commands on behalf of any authorized system user. cron is intended mainly for regularly scheduled recurring activities, and at is most useful for scheduling single commands for execution in the future. 18.4.1. Using cron The cron facility consists of two programs (There is no individual program called cron, which is the overall name given to the facility. If you execute man cron, however, you will see the manpage for crond.):
crond This is the cron daemon. This is the process that executes your instructions. It starts at system initialization time and runs in the background thereafter.
crontab This is the cron table manipulation program. This program gives you access to your cron table or crontab file. Each authorized user may have his own crontab file to run commands and processes on a regular basis. The cron daemon wakes up every minute and examines all crontab files, executing any commands scheduled for that time. 18.4.1.1. User crontab files To use the cron facility, users do not need to interact directly with the crond daemon. Instead, each system user has access to the cron facility through her crontab file. These files are stored together in a single directory (usually /var/spool/cron) and are created and maintained using the crontab utility.
Syntax crontab [options]
Description View or edit crontab files.
Frequently used options
-e Interactively edit the crontab file. Unless otherwise specified in either the EDITOR or VISUAL environment variables, the editor is vi.
-l Display the contents of the crontab file.
-r Remove the crontab file.
-u user Operate on user's crontab file instead of your own. Only root can edit or delete the crontab files of other users.
Example Display the crontab file for user jdoe: # crontab -l -u jdoe
Edit your own crontab file: $ crontab -e
crontab files use a flexible format to specify times for command execution. Each line contains six fields: minute hour day month dayofweek command
These fields are specified as follows: Minute (0 through 59) Hour (0 through 23) Day of the month (1 through 31) Month (1 through 12 or jan through dec) Day of the week (0 through 7where 0 or 7 is Sundayor sun through sat) Command (any valid command, including spaces and standard Bourne shell syntax)
For example, to execute myprogram once per day at 6:15 a.m., use this crontab entry: # run myprogram at 6:15am 15 6 * * * myprogram
Lines that begin with the pound sign (#) are comment lines and are ignored by crond. Comments must begin on a new line and may not appear within commands. The asterisks in this crontab are placeholders and match any date or time for the field where they're found. Here, they indicate that myprogram should execute at 6:15 a.m. on all days of the month, every month, all days of the week. Each of the time specifications may be single, list (1,3,5), or range (1-5 or wed-fri) entries or combinations thereof. To modify the previous example to execute at 6:15 and 18:15 on the 1st and 15th of the month, use: # run myprogram at 6:15am and 6:15pm on the 1st and 15th 15 6,18 1,15 * * myprogram
As you can see, the time specifications are very flexible. Because the cron daemon evaluates each crontab entry when it wakes up each minute, it is not necessary to restart or reinitialize crond when crontab entries are changed or new files are created. 18.4.1.2. System crontab files In addition to crontab files owned by individual users, crond also looks for the system crontab files /etc/crontab and files in the directory /etc/cron.d. The format for these system crontabs differs slightly from user crontabs. System crontabs have an additional field for a username between the time specifications and the command. For example: # /etc/crontab # run myprogram at 6:15am as root 15 6 * * * root myprogram
In this example, myprogram will be executed by cron as the root user. System crontab files located in /etc/cron.d are of the same form as /etc/crontab, including the extra user field. These files are usually associated with some package or service that includes a system crontab. Allowing a collection of files in /etc/cron.d allows software installation and upgrade procedures to keep the cron configuration up-to-date on an individual package basis. In most cases, however, you won't need to change the crontab files in /etc/cron.d. | On the Exam | Memorize the sequence of time/date fields used in crontab files. |
On most Linux distributions, /etc/crontab contains some standard content to enable the execution of programs and scripts on the minute, hour, week, and month. These arrangements allow you to simply drop executable files into the appropriate directory (such as /etc/cron.hourly), where they are executed automatically. This eliminates cron configuration altogether for many tasks and avoids cluttering the root crontab file with common commands. 18.4.2. Using at The cron system is intended for the execution of commands on a regular, periodic schedule. When you need to simply delay execution of a command or a group of commands to some other time in the future, you should use at. The at facility accepts commands from standard input or from a file.
Syntax at [-f file] time at [options]
Description In the first form, enter commands to the at queue for execution at time. at allows fairly complex time specifications. It accepts times of the form HH:MM to run a job at a specific time of day. (If that time is already past, the next day is assumed.) You may also specify midnight, noon, or teatime (4 p.m.), and you suffix a time of day with AM or PM for running in the morning or evening. You can also say what day the job will be run by giving a date in month-day form, with the year being optional, or by giving a date in MMDDYY, MM/DD/YY, or DD.MM.YY form. The date specification must follow the time-of-day specification. You can also give times like now + count time-units, where time-units can be minutes, hours, days, or weeks; you can tell at to run the job today by suffixing the time with today, and you can tell it to run the job tomorrow by suffixing the time with tomorrow. If -f file is given, commands are taken from the file; otherwise, at will prompt the user for commands. In the second form, list or delete jobs from the at queue.
Frequently used options
-d job1 [, job2, ...] Delete jobs from the at queue by number (same as the atrm command).
-l List items in the at queue (same as the atq command).
Example1 Run myprogram once at 6:15 p.m. tomorrow: $ at 6:15pm tomorrow at> myprogram at> ^D
In the previous code listing, ^D indicates that the user typed Ctrl-D on the keyboard, sending the end-of-file character to terminate the at command.
Example2 Run commands that are listed in the file command_list at 9 p.m. two days from now: $ at -f command_list 9pm + 2 days
List items in the at queue (root sees all users' entries): $ at -l
Remove job number 5 from the at queue: $ at -d 5
Using at to schedule jobs for delayed execution, such as while you're asleep or on vacation, is simple and doesn't require creation of a recurring cron entry. 18.4.3. Controlling User Access to cron and at In most cases, it is safe to allow users to use the cron and at facilities. However, if your circumstances dictate that one or more users should be prohibited from using these services, two simple authorization files exist for each: cron.allow, cron.deny at.allow, at.deny
These files are simply lists of account names. If the allow file exists, only those users listed in the allow file may use the service. If the allow file does not exist but the deny file does, only those users not listed in the deny file may use the service. For cron, if neither file exists, all users have access to cron. For at, if neither file exists, only root has access to at. An empty at.deny file allows access to all users and is the default. |
