Using Linux:Managing Scheduling Services






-->















Previous
Table of Contents
Next




The rc Files

This section focuses particular attention on the lines in the inittab file that call the rc files (refer to Listing 26.1):


l0:0:wait:/etc/rc.d/rc 0
l1:1:wait:/etc/rc.d/rc 1
l2:2:wait:/etc/rc.d/rc 2
l3:3:wait:/etc/rc.d/rc 3
l4:4:wait:/etc/rc.d/rc 4
l5:5:wait:/etc/rc.d/rc 5
l6:6:wait:/etc/rc.d/rc 6


What is actually being called is the /etc/rc.d/rc file. This file is receiving an argument for the run level. At the end of this file, the following commands are called:


# Now run the START scripts.
for i in /etc/rc.d/rc$run level.d/S*; do
# Check if the script is there.
[ ! -f $i ] && continue
# Check if the subsystem is already up.
subsys=${i#/etc/rc.d/rc$run level.d/S??}
[ -f /var/lock/subsys/$subsys ] && \
[ -f /var/lock/subsys/${subsys}.init ] && continue
# Bring the subsystem up.
$i start
done


This loop is checking for a directory associated with that particular run level. If the directory exists, each process in that directory is initiated. After all other rc files are run, /etc/rc.d/rc.local is initiated. This is the best place to put your changes to the system. Note that this file overwrites the /etc/issue file at every bootup. So if you want to make changes to the banner that is displayed at logon, make your changes in the rc.local file rather than in the /etc/issue file.
With inittab and rc files, you have an excellent set of tools for starting processes at boot time, capturing keystroke events (such as Alt+Ctrl+Delete), and reacting in a proactive manner.
Configuring crontab Scheduling Service

Certain processes must be run at a specific time, over and over again. An example of this might be a backup process that is kicked off each night, or a log analyzer that must be run every minute. These processes are run at specific times or on specific days; the rest of the time, they are not running.

cron is started from either rc or rc.local and returns immediately, so there is no need to background this command. cron searches /var/spool/cron for entries that match users in the /etc/passwd file; found entries are loaded into memory. cron also searches /etc/crontab for system entries.
cron “wakes up” once a minute and does several things:

•  It checks the entries that it knows about and runs any commands that are scheduled to run.
•  It determines whether the modtime on the cron directory has changed.
•  If the modtime on the cron directory has changed, cron checks each of the files and reloads any that have changed.



Do I need to restart cron after a change?
Since cron checks for changes every minute, it is unnecessary to restart cron when the cron files are changed.

Enabling crontab Service

It is crontab’s job to schedule these services. The cron daemon reads the crontab file; each user can have his or her own version of this file. Flags associated with the crontab application specify whether to open crontab for listing, editing, or removal.
The syntax for the crontab program is as follows:


crontab [-u user] file
crontab [-u user] -l -e -r


These parameters indicate the following:


•  The -u option tells the system the name of the user whose crontab file is about to be used. If the -u option is omitted, the system assumes that you are editing your crontab. The switch user (su) command can confuse crontab, so if you are su’ing to someone else, be sure to use the -u option.
•  The -l option tells crontab to list the file to standard output (in other words, to list the file).
•  The -e option tells crontab to edit the file. cron uses the editor defined by EDITOR or by VISUAL. If neither is defined, it defaults to vi. When the file is exited, it is immediately placed in the correct location and the time stamp is updated.
•  The -r option removes the specified crontab file. If no file is specified, it removes that user’s crontab file.

crontab Entries

Two types of entries are allowed in the crontab file:

•  Environment settings
•  Command settings

These entries are discussed in the following sections.

Environment Settings
Environment settings use the following form:


name = value


cron already knows about several environment settings. For example, SHELL is set to /bin/sh. Other environment variables, such as LOGNAME and HOME, are associated with the owner of the file. SHELL and HOME can be overridden in the script; LOGNAME cannot. If MAILTO is defined (that is, MAILTO actually appears in a line in the crontab file and is not set to “”), it mails any messages to the specified user. The following shows MAILTO set to a specific user:


# mail any output to ’paulc’, no matter whose crontab this
is MAILTO=paulc






Previous
Table of Contents
Next