Ict-innovation/LPI/107.2
107.2 Automate System Administration Tasks
editCandidates should be able to use cron or anacron to run jobs at regular intervals and to use at to run jobs at a specific time.
Key Knowledge Areas
- Manage cron and at jobs.
- Configure user access to cron and at services.
1. Cron Jobs
editA cron is a time-scheduled job on the UNIX system. For any administrative tasks that have to be run regularly, such as back-ups and Network Services, the cron facility is the best way to do it. This section is about the cron, anacron and other such facilities.
The cron facility consists of the crond daemon and a set of tables – crontabs - describing what work is to be done, when and how frequently. The daemon, which is started by init, wakes up every minute and checks the crontabs to determine what is to be done. Users manage crontabs using the crontab command.
Cron jobs can be run as shell scripts, and are better designed to accept no parameters.
crontabs
To create a crontab, the crontab command with the -e (for "edit") option will open a text editor where your specifications of the cron job can be specified. Every crontab entry will contain six fields:
Minute, hour, day of the month, month of the year, day of the week and String to be executed by sh.
The respective ranges for the time fields are: 0-59, 0-23, 1-31 and 1-12, 0-6 (Sunday=0).
NOTE: For all time fields, you can specify a range, or a single unit of time. You can specify the day of the week, using its short name: sun, mon, tue, and so on.
The final field will always be interpreted as a string to pass to the Bash.
Crontabs can use special characters, like % = newline, but these have to be preceded with a backslash (\). The line up to the first % is passed to the shell, while any line(s) after the % are passed as standard input.
Crontab Example:
|
0,30 20-23 * 8 mon-fri /home/tux/backup.sh |
Here, the back up shell script is executed at the 0th and 30th minutes (every 30 minutes), for the hours between 8 P.M and 11 P.M. every monday to Friday, during August. See the man page for crontab(5) for details on additional ways to specify times./ For further details on how to specify times please see the man page for crontab.
Cron jobs output can is usually sent as an email to the user who set up the cron job. Normally, like other system processes, the syslog facility will capture whatever the cron job did. Below is an example of a mailed report.
|
From tux@it.northpole.com Mon Jul 2 23:00:02 2010 Date: Mon, 2 Jul 2010 23:00:01 -0400 From: root@it.northpole.com (Cron Daemon) Subject: Cron <tux@it> /home/tux/backup.sh Content-Type: text/plain; charset=UTF-8 Auto-Submitted: auto-generated X-Cron-Env: <SHELL=/bin/sh> X-Cron-Env: <HOME=/home/tux> X-Cron-Env: <PATH=/usr/bin:/bin> X-Cron-Env: <LOGNAME=tux> X-Cron-Env: <USER=tux>
|
Location of the crontabs
All crontabs are stored in /var/spool/cron/*name of the user who created it*. Thus crontab is a suid program it can only run by a user with root authority.
The cron facility checks some more directories as well i.e. /etc/crontab and /etc/cron.d. As these are not user but system crontabs they have one more field between "day" and "command". This field just defines for which user the command should be run (root in normal case).
/etc/crontab example
|
SHELL=/bin/bash PATH=/sbin:/bin:/usr/sbin:/usr/bin MAILTO=root HOME=/ # run-parts 01 * * * * root run-parts /etc/cron.hourly 02 4 * * * root run-parts /etc/cron.daily 22 4 * * 0 root run-parts /etc/cron.weekly 42 4 1 * * root run-parts /etc/cron.monthly |
In this case, the cron jobs are done by the run-parts command, whereas the /etc/crontab simply controls the timing.
NOTE: Note also that the crontab can include shell variables that have been set before the commands are run. All these cronjobs are run for the user root.
Anacron - for non 24/7 machines
Whereas the cron facility is ideal on computer systems that run continuously, and as such jobs that run hourly, some systems may require to be turned off every now and then. Consequently, you can only schedule jobs that run daily, weekly or monthly. A facility to do this is called anacron (for "anachronistic cron").
Anacron will keep timestamp files in /var/spool/anacron as a way to record when jobs are run. Anacron works by checking to see if the required number of days has passed since the job was last run and then determines to run it if necessary. The anacrontab is stored in /etc/anacrontab, and may contain environment variables. Every anacron job has four fields.
Time – Delay – Job-identifier - Command
The time is always a number of days, but can be specified as @weekly, @monthly to ensure that a job runs only then. The delay is the number of minutes to wait after the job is due to run before actually starting it. This feature can be useful if you do not want to flood the system with multiple jobs! You can use this to prevent a flood of jobs when a system first starts.
NOTE – Unlike the specific jobs contained in them, both /etc/crontab and /etc/anacrontab – can only be updated by direct editing, not by crontab -e
Sometimes you just want to run a job once. Linux provides the at command. The instructions to be executed are read from a file specified with the -f option, or from stdin if -f is not used. To display the time for the job to run, you can use the -v option. Below is an example:
|
$ at -f backup.sh -v 10:25 Wed Jul 7 10:25:00 2010
|
Job output from at
|
From tux@it.northpole.com Wed Jul 7 10:25:00 2010 Date: Wed, 7 Jul 2010 10:25:00 -0400 From: Tux <tux@it.northpole.com> Subject: Output from your job 5
|
The at command also has a -q option. When used, this option increases the nice value for the job. Be sure to look at the man pages for more details on these features.
Managing Jobs
You can use the crontab command with the -l option to list your crontab, and use the atq command to display the jobs you have queued using the at command, as shown in below.
Displaying scheduled jobs
|
$ crontab -l 0,30 20-23 * 8 mon-fri /home/tux/backup.sh $ atq 13 Wed Jul 7 02:00:00 2010 a tux 14 Sat Jul 10 02:00:00 2010 a tux 15 Sun Jul 11 22:00:00 2010 a tux 16 Tue Jul 13 02:00:00 2010 a tux |
NOTE – For details on the actual command scheduled for execution by at, you can use the -c option and the job number. You will notice that most of the environment that was active at the time the at command was issued is saved with the scheduled job.
Deleting Jobs
You can delete all scheduled cron jobs using the crontab command with the -r option as shown below:
|
$ crontab -l 0,30 20-23 * 8 mon-fri /home/tux/backup.sh $ crontab -r $ crontab -l no crontab for tux |
You can delete system cron or anacron jobs, by editing the /etc/crontab, /etc/anacrontab, or by editing and/or deleting files in the /etc/cron.d directory.
For jobs scheduled using the at command, you can delete them using the atrm command with the job number. Multiple jobs have to be separated by a space.
|
$ atq 13 Wed Jul 7 02:00:00 2010 a tux 14 Sat Jul 10 02:00:00 2010 a tux 15 Sun Jul 11 22:00:00 2010 a tux 16 Tue Jul 13 02:00:00 2010 a tux $ atrm 16 14 15 $ atq 13 Wed Jul 7 02:00:00 2010 a tux |
Managing non-root user access
There may be situations when a non root user needs to have access to the crontab and the cron facility. In such a case, all you have to do is create the file /etc/cron.allow (if it does not already exist), and any non-root user must be listed in it. In contrasting effect, if /etc/cron.deny does exist, a non-root user who is listed in it cannot use crontab or the cron facility. If the /etc/cron.deny file is empty (and this is the default), all users are allowed to use the cron facility.
The following is a partial list of the files, terms and utilities that were used.
- /etc/cron.{d,daily,hourly,monthly,weekly}
- /etc/at.deny
- /etc/at.allow
- /etc/crontab
- /etc/cron.allow
- /etc/cron.deny
- /var/spool/cron/*
- crontab
- at
- atq
- atrm