Chapter 8
Automating tasks: the system never sleeps
|
|
|
|
|
![](gif/black.gif) |
In this chapter: |
|
|
|
![*](gif/bullet.gif) ![](gif/clear.gif) |
Manipulating cron to schedule recurring tasks
|
![*](gif/bullet.gif) ![](gif/clear.gif) |
Handy tools that ease system maintenance
|
![*](gif/bullet.gif) ![](gif/clear.gif) |
SuSE's default maintenance tasks
|
![*](gif/bullet.gif) ![](gif/clear.gif) |
Scheduling one-time jobs with the at command
|
|
|
|
![](gif/black.gif) |
|
Unix administration is often a complex task because many functions
require regular, ongoing attention. Some examples are log files that
may become too cumbersome and need to be compressed or deleted, system
databases (that is, for locate or the man page index) that require
regular updates, or files that need to be cleaned up. Most of these
can be handled automatically by creating scripts that perform
prescribed maintenance tasks.
The at daemon atd can be used to start a
job once at a specified time. This is not as useful as having
regularly scheduled maintenance, but it may be useful for unique tasks
that you have to deal with. SuSE Linux, like most (if not all) Unix
systems, employs the cron daemon to do just this --
schedule special tasks at given intervals. This chapter shows how
cron works, which tasks are predefined by SuSE, and how
to add new tasks to the cron scheduling mechanism. A
short section covers the atd command and how to get jobs
executed at later time.
|
8.1 | Using cron to automate tasks |
|
The cron daemon is a system service that runs scripts or
single commands at a given interval. It is available to root and
every user on the system. In addition to user-specified tasks, system
tasks can be scheduled by running cron.
Pay attention to the man behind the curtain: Each user sets up a
crontab file that specifies which jobs should be executed
at a designated time. A crontab file contains
instructions to the cron daemon in this format:
run-this-command-at-this-time-on-this-date. Commands in any given
crontab will be executed as the user who owns the crontab.
|
8.1.1 | The crontab's format |
|
In the crontab, blank lines, leading spaces, and tabs are
ignored. Lines whose first nonspace character is a hash mark (#) are
read as comments and are ignored. Note that comments are not allowed
on the same line as the cron command because they will be
taken as part of the command. Similarly, comments are not allowed on
the same line as environment variable settings.
An active line in a crontab will be either an environment setting or
a cron command. An environment setting follows this
format:
|
| name = value
|
|
The value string may be placed in quotation marks (single or double,
but must remain consistent) to preserve leading or trailing
blanks. The environment variables may be used in the cron
commands. The cron daemon predefines the variables
LOGNAME (user name), HOME (the user's home
directory), and SHELL (the user's login shell). The
output of the commands is sent to the user by E-mail. If the variable
MAILTO is defined (and not empty), mail is sent to the
user indicated. If MAILTO is defined but empty (
MAILTO=""), no mail will be sent.
The command lines have five time and date fields, followed by a
command. Commands are executed by cron when the minute,
hour, and month of year fields match the current time, and when at
least one of the two day fields (day of month or day of week) matches
the current time.
The cron daemon examines cron entries once
every minute. The time and date fields are displayed in Table 8-1
.
|
Table 8-1 |
Valid time and date specifications for cron |
|
Field |
Allowed values |
minute |
0-59 |
hour |
0-23 |
day of month |
0-31 |
month |
0-12 (or names; see below) |
day of week |
0-7 (0 or 7 is Sun, or use names) |
|
|
A field may be an asterisk (*), which always stands for
first to last. A range of numbers is allowed. Ranges are two numbers
separated by a hyphen. The specified range is inclusive. For
example, 8-11 for an hour's entry defines command execution at hours
8, 9, 10, and 11.
Lists are also legal. A list is a set of numbers (or range of numbers)
separated by commas. For example: 1,2,5,9,0-4,8-12.
Step values can be used in conjunction with ranges. Following a range
with /number specifies that alternating
numerical values in the range can be used. For example,
0-23/2 can be used in the hour field to specify command
execution every other hour. Steps are also permitted after an
asterisk, so if you want to say every two hours, just use
*/2.
Names can be used for the month and day-of-week fields. Use the
first three letters of the desired day or month (the case is
unimportant). Ranges or lists of names are not allowed in this
instance.
The rest of the line specifies the command to be run. The entire
command portion of the line, up to a newline or percent
(%) character, will be executed by the shell specified in
the SHELL variable. Percent signs (%) in the
command, unless escaped with a backslash, will be
changed into newline characters, and all data after the first
% will be sent to the command as standard input.
The day of a command's execution can be specified by two fields:
day-of-month and day-of-week. If both fields are restricted (that is,
aren't *), the command will be run when either field
matches the current time. For example, 30 4 1,15 * 5
would initiate a command to run at 4:30 a.m. on the 1st and 15th of
each month, as well as every Friday.
As an example, crontab could look like this:
|
| # use /bin/sh to run commands, no matter what the login shell is
SHELL=/bin/sh
# run five minutes after midnight every day and ignore the output
5 0 * * * $HOME/bin/daily.job >> $HOME/tmp/out 2>&1
# Don't forget about the Bay Area Linux User Group meeting
# every second thursday of the month
0 10 8-14 * tue mail -s "BALUG meeting" $LOGNAME%BALUG meeting tonight at 7pm
|
|
|
8.1.2 | Installing a user crontab |
|
User crontabs are stored in /var/cron/tabs/ and are named
after the user's login name. However, you should never edit these
files directly. The command to edit, install, list, or delete a
crontab is crontab. The crontabs can be edited by users,
but only root is allowed to edit crontabs for other users. The
command crontab follows the arguments shown in Table 8-2
.
|
Table 8-2 |
Parameters of the crontab command |
|
Parameter |
Meaning |
-u |
user Name of the user whose crontab is to be altered (only root can use this feature) |
-l |
Displays the current crontab on standard output |
-r |
Removes current crontab |
-e |
Edits the current crontab |
|
|
So to create or edit a crontab, just call
crontab -e. This will start the editor specified in the
VISUAL or EDITOR environment variable
(defaults to vi, if both are undefined) and will present
your installed crontab, or an empty buffer if you call it for the
first time. After the user exits the editor, the new crontab will be
installed in the proper directory and the specified jobs will be
executed at the scheduled times.
|
8.1.3 | The system crontab |
|
In addition to individual user's crontabs, there is a central crontab
for system administration. This crontab is stored in the file
/etc/crontab. The syntax is almost the same as that for
altering user crontabs. The only exception is that there is an
additional column that allows root to specify with which user's
permissions a job request will be issued. The name of the user
belongs between the time/date fields and the command:
|
| minute hour day-of-month month day-of-week user command
|
|
You can of course use the root crontab to do most of the maintenance
tasks, too. Certain jobs104 require the use of a special user ID; that
is, expiring news has to be performed as user news, and some
UUCP-related tasks are easily ruined if they are not performed as user
uucp. Rather than switch user IDs with the su command in
the root crontab, you can specify the user in the system crontab,
which is more convenient and easier to read. SuSE uses /etc/crontab to
start up a range of useful scripts, as you can see in the next
section.
|
8.2 | Standard maintenance tasks set up by SuSE |
|
As we've said,cronis a perfect tool to ease
administrative tasks that need to be taken care of on a regular
basis. SuSE has done a good job of providing a set of scripts for the
most important tasks. All of these scripts are scheduled by the system
crontab in /etc/crontab. SuSE also implemented an add-on
mechanism that makes adding or removing jobs even easier.
This works with a subdirectory within /etc that sets
scripts to be executed every hour, day, week, or month, as shown in
Table 8-3
. Every script within these directories will be
executed once in the specified time frame.
|
Table 8-3 |
Directories for regular run scripts |
|
Directory |
Schedule |
/etc/cron.hourly/* |
run every hour |
/etc/cron.daily/* |
run once a day |
/etc/cron.weekly/* |
run once a week |
/etc/cron.monthly/* |
run once a month |
|
|
SuSE provides the script aaa_base, which is run once a
day. It uses several settings from /etc/rc.config and performs the
tasks described in the following sections.
|
8.2.1 | Log files are checked for size, ownership, and permission |
|
The file /etc/logfiles contains a list of various log
files and their maximum size, permission levels, and ownership
information. Each of these files will be reviewed. If a file's size is
greater than the allowed maximum size, the file will be compressed and
moved to a backup copy named
filename-date.gz. If
the permissions or the ownership is different than specified, this
will be reconciled. A notice is sent to root if a backup copy has
been made or if ownership or permission information has been
revised.
You can add files to the list. Edit the file
/etc/logfiles and add one line per file to be checked:
|
| Filename maximum-size permissions owner.group
|
|
The filename may include wildcards. The maximum size must be prefixed
with a plus sign (+) and have a lowercase k
to indicate that it's given in kilobytes. The permissions are given in
octal notation, and the owner and group names can be written either
as user/group IDs or names.
Only if the value of MAX_DAYS_FOR_LOG_FILES in
rc.config is greater than zero will the log file check be
performed. Backup copies of log files will be removed after the number
of days in MAX_DAYS_FOR_LOG_FILES has been reached.
With this scheme, you can make sure that log files don't get too
big. If they do, they'll be compressed and stored for a period of
time, in case you need to review them. After the save period, the
backups will be removed so that your hard drive doesn't become filled
with old and often useless information.
|
8.2.2 | Old files in various locations are removed |
|
If the value of MAX_DAYS_IN_TMP (also set in
/etc/rc.config like all other variables mentioned in this
section) is not zero, all files in the directories specified in
TMP_DIRS_TO_CLEAR will be removed when they are older
than the number of days specified. Files owned by users listed in
OWNER_TO_KEEP_IN_TMP won't be removed.
This feature is disabled by default; (MAX_DAYS_IN_TMP is set to 0).
Old YaST log files will be removed after
MAX_DAYS_FOR_LOG_FILES days has been reached.
Preformatted versions of man pages will be removed after the default
period -- 7 days -- if DELETE_OLD_CATMAN is set to
yes. The length of time that you can keep man pages can be modified
simply by setting CATMAN_ATIME to the number of days you
want to retain these files.
|
8.2.3 | System databases are updated and/or backed up |
|
Some databases need to be updated on a regular basis. The database for
the command locate andthe man page index are regenerated each
day. This will be done only if RUN_UPDATEDB is yes. The
locate database will contain information only about files in
directories not listed in UPDATEDB_PRUNEPATHS. It will
run as the user given in RUN_UPDATEDB_AS. By default, no
NFS mounted directories will be included. However, if you like to have
information about these directories, you can list them in
UPDATEDB_NETPATHS.
The search will be done with the permissions of the user whose ID is
listed in UPDATEDB_NETUSER.
All these variables are used to increase security. Because locate can
be used by anyone on the system, you want to make sure that
sensitive information is excluded from its database.
If the RPM database has changed since the last run, a backup will be
created. If the original database is corrupted, this will allow you
to recover data.
|
8.2.4 | Core files are searched for |
|
Core files are usually created when an application crashes. They can
be used to debug the application because they represent a memory
dump of the application at the moment of the crash.
But if you are not in the process of debugging the application, core
files are almost useless. This is why all users receive a notice about
core files they own. All core files older than
MAX_DAYS_FOR_CORE are reported to the user. They will
automatically be deleted when172 DELETE_OLD_CORE is set to yes.
|
8.2.5 | CMOS battery is checked |
|
If possible, the system checks the life of the battery that keeps the
CMOS fresh when the system is turned off. A warning will be sent to
root if a problem has been detected.
|
8.2.6 | /root/bin/cron.daily.local is started |
|
If the file /root/bin/cron.daily.local exists, it will be
executed right after aaa_base is done. You can add your own cleanup or
maintenance routines here.
This script is executed daily, usually at night. If you turn your
machine off overnight, it'll be run shortly after you reboot.
|
8.3 | Adding customized tasks |
|
If you have some system-wide task you need to set to run every hour,
day, week, or month, simply write a script to perform the task and
put it in the appropriate directory, as shown in Table 8-3.
For user-specific tasks, implement user crontabs such as those
described previously.
|
8.4 | Executing a job once at a specified time |
|
After cron, next in importance is at,
another service that schedules jobs at a given time. The difference is
that cron executes jobs repeatedly, whereas
at executes them once and at a specified time.
The at service allows fairly complex time specifications. It accepts
times formatted as HH:MM (two-digit hour specification, followed by a
colon and a two-digit minute specification) to run a job at a specific
time of day. (If that time is already past, it is assumed that the job
is to be run the following day.) You may also specify midnight, noon,
or tea time (4 p.m.), and you can have a time-of-day suffixed with AM
or PM for running in the morning or the evening. You can also state
what day the job will be run by giving a date in the form month-name
day with an optional year, or giving the date in the form MMDDYY, or
MM/DD/YY, or DD.MM.YY. When specifying the date, you must follow by
specifying the time-of-day. You can also give times such as now
+count time-units, where the 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 run the job
tomorrow by suffixing the time with tomorrow.
For example, to run a job at 4 p.m. three days from now, you would
enter:
|
| at 4pm + 3 days
|
|
To run a job at 10 a.m. on July 31, you would enter:
|
| at 10am Jul 31
|
|
and to run a job at 1 a.m. tomorrow, you would state:
|
| at 1am tomorrow
|
|
After you call at, it will prompt you for the command to
run at this time. The output of this command, or list of commands,
will be mailed to the user who spooled the job. Say that you want to
impress your boss by sending him or her an e-mail message really early
in the morning, to make him or her think you started working
early. You could do this by spooling an at job for 6 a.m. the next
day:
|
| at 6am tomorrow
at> echo "Hi, you want coffee?" | mail -s "Coffee?" boss@work.com
|
|
You can list the spooled jobs with atq and remove them
with atrm job-number. Other features of at
include handling several queues and fixing the execution of the job
dependent on the system load. Review the man page at(1)
for more details. The at service is seldom used, so this short
overview will do for most uses.
|
![](gif/black.gif) |
Summary: |
|
Thecronservice can be used to schedule jobs on a regular
basis. Every user can enter jobs into this scheduling mechanism. SuSE
sets up some standard tasks that are executed once a day to perform
maintenance, such as compressing log files and keeping the system
clean.
SuSE also added a mechanism that makes it easy to schedule jobs every
hour, day, week, or month, just by putting a script into a specific
directory in /etc.
In addition to cron, the at command is available to
schedule a job once at a given time.
|
![](gif/black.gif) |