 |
» |
|
|
|
NAMErc — general purpose sequencer invoked upon entering new run level DESCRIPTIONThe
rc
shell script is the general sequencer invoked upon entering a new
run level via the
init N
command (where
N
equals 0-6).
The script
/sbin/rc
is typically invoked by
the corresponding entry in the file
/etc/inittab
as follows:
sqnc:123456:wait:/sbin/rc </dev/console >/dev/console 2>&1 /sbin/rc
is the startup and shutdown sequencer script.
There is only one
sequencer script and it
handles all of the sequencer directories.
This script
sequences the scripts in the appropriate
sequencer directories in alphabetical order
as defined by the shell and
invokes them as either
startup or kill scripts. If a transition from a lower to a higher run level
(i.e.,
init
state) occurs,
the start scripts for the new run level
and all intermediate levels between the
old and new level are executed.
If a transition from a higher to a lower run level occurs,
the kill scripts
for the new run level
and all intermediate levels between the old
and new level are executed. If a start script link (e.g.,
/sbin/rcN.d/S123test)
in sequencer
N
has a stop action,
the corresponding kill script should be placed in sequencer
N-1
(e.g.,
/sbin/rcN-1.d/K200test).
Actions started in level
N
should
be stopped in level
N-1.
This way, a system shutdown (e.g., transition from
level 3 directly to level 0) will result in all subsystems being stopped. Start and Kill ScriptsIn many cases,
a startup script will have both a start and a kill action.
For example, the
inetd
script starts the Internet daemon in the
start case, and kills that process in the
stop case.
Instead of two separate scripts,
only one exists,
which accepts both the
start
and
stop
arguments and
executes the correct code.
In some cases, only a
start action will be applicable.
If this is the case,
and if the
stop
action is specified,
the script should produce a usage message
and exit with an error.
In general,
scripts should look at their arguments
and produce error messages if bad
arguments are present.
When a script executes properly,
it must exit with
a return value of zero.
If an error condition exists,
the return value
must be nonzero. Naming ConventionsThe startup and shutdown scripts (referred to as
startup scripts hereafter)
exist in the
/sbin/init.d
directory,
named after the subsystem they control.
For example, the
/sbin/init.d/cron
script controls starting up the
cron
daemon.
The contents of sequencer directories
consist of symbolic links to startup
scripts in
/sbin/init.d.
These symbolic links must follow a strict
naming convention, as noted in the various fields of this example:
where the fields are defined as follows:
- rc2.d
The sequencer directory is numbered to reflect the
run level for which its contents will be executed.
In this case,
start scripts in this directory will
be executed upon entering run level 2 from run level 1,
and kill scripts will be executed upon entering
run level 2 from run level 3. - S
The first character of a sequencer link name determines
whether the script is executed as a start script (if the
character is
S),
or as a kill script (if the character is
K). - 060
A three digit number is used for sequencing scripts within
the sequencer directory.
Scripts are executed by type
(start or kill) in alphabetical order as defined by the
shell.
Although it is not recommended,
two scripts may share the same sequence number. - cron
The name of the startup script follows the sequence number.
The startup script name must be the same name as the script to
which this sequencer entry is linked.
In this example,
the link points to
/sbin/init.d/cron. Note that short file name systems require file names
of 14 or less characters.
This means that the fourth field is limited to 10 or fewer characters. Scripts are executed in alphabetical order.
The entire file name of the script
is used for alphabetical ordering purposes. When ordering start and kill script links,
note that subsystems started in any
given order should be stopped in the reverse order to eliminate any
dependencies between subsystems.
This means that kill scripts will generally
not have the same numbers as their start script counterparts.
For example,
if two subsystems must be started in a given order due to dependencies
(e.g.,
S111house
followed by
S222uses_house),
the kill counterparts to these
scripts must be numbered so that
the subsystems are stopped in the opposite
order in which they were started
(e.g.,
K555uses_house
followed by
K777house). Also keep in mind that kill scripts
for a start script in directory
/sbin/rcN.d
will reside in
/sbin/rc(N-1).d.
For example,
/sbin/rc3.d/S123homer
and
/sbin/rc2.d/K654homer
might be start/kill counterparts.
ArgumentsThe startup/shutdown scripts should be able to recognize the following
four arguments (where applicable):
- start
The
start
argument is passed to scripts whose names
start with
S.
Upon receiving the
start
argument,
the script should perform its start actions. - stop
The
stop
argument is passed to scripts whose names
start with
K.
Upon receiving the
stop
argument,
the script should perform its stop actions. - start_msg
The
start_msg
argument is passed to scripts whose
names start with
S
so that the script can report back
a short message indicating what the
start action will do.
For instance,
when the
lp
spooler script is invoked
with a
start_msg
argument, it echoes
Starting the LP subsystem This string is used by the startup routines.
Scripts given just the
start_msg
argument will only print a message and not perform any actions. - stop_msg
The
stop_msg
argument is passed to scripts whose
names start with
K
so that the script can report back
a short message indicating what the
stop action will do.
For instance, when the
lp
spooler script is invoked
with a
stop_msg
argument, it echoes
Stopping the LP subsystem This string is used by the shutdown checklist.
Scripts given just the
stop_msg
argument will only print a message and not perform any actions.
Script OutputTo ensure proper reporting of startup events,
startup scripts are
required to comply with the
following guidelines for script output.
Status messages, such as
must be directed to stdout.
All error messages must be directed to stderr. Script output, both stdout and stderr, is redirected to log file
/etc/rc.log,
unless the startup checklist mode is set to the raw mode.
In this case, all output goes to the console.
All error messages should be
echoed to stdout or stderr. Startup scripts are not allowed to send
messages directly to the console,
or to start any daemons that immediately write to the console.
This restriction
exists because these scripts are
now started by the
/sbin/rc
checklist wrapper.
All script output should go to either stdout or stderr,
and thus be captured in a log file.
Any console output will be garbled. When a startup script returns an exit code of
3,
/sbin/rc
can display a specific message on the console prior
to rebooting the system. This is achieved by creating
a text file named
/etc/rc.bootmsg
containing the text to be displayed to the console. Note that
/sbin/rc
deletes this file after displaying
the message, so startup scripts need to write this
file each time a specific message is required to be
displayed on console prior to reboot.
RETURN VALUEThe return values for startup scripts are as follows:
- 0
Script exited without error. - 1
Script encountered errors. - 2
Script was skipped due to overriding control variables
from
/etc/rc.config.d
files, or for other reasons, and
did not actually do anything. 3
Script will automatically reboot the system. - 4
Script exited without error and started a process in background mode. - >4
For return values greater than
4
the action is same as return value
1,
script encountered errors.
|
Printable version
