Chapter 3. System
Initialization and Boot
The /etc/inittab file controls the initialization
process.
The /etc/inittab file supplies the script to the init command's
role as a general process dispatcher. The process that constitutes the majority
of the init command's process dispatching activities is the /etc/getty
line process, which initiates individual terminal lines. Other processes
typically dispatched by the init command are daemons and the shell.
The /etc/inittab file is composed of entries that are position-dependent and
have the following format:
Identifier:RunLevel:Action:Command
Each entry is delimited by a newline character. A backslash (\) preceding a
newline character indicates the continuation of an entry. There are no limits
(other than maximum entry size) on the number of entries in the /etc/inittab
file. The maximum entry size is 1024 characters. The entry fields are:
-
Identifier
- A one or two character field that uniquely identifies
an object.
-
RunLevel
- The run level at which this entry can be processed.
The run level has the following attributes:
- Run levels effectively correspond to a configuration of processes in the
system.
- Each process started by the init command is assigned one or
more run levels in which it can exist.
- Run levels are represented by the numbers 0 through 9. For example, if
the system is in run level 1, only those entries with a 1 in the runlevel field
are started.
- When you request the init command to change run levels, all
processes without a matching entry in the runlevel field for the target run
level receive a warning signal (SIGTERM). There is a 20-second grace period
before processes are forcibly terminated by the kill signal (SIGKILL).
- The runlevel field can define multiple run levels for a process by
selecting more than one run level in any combination from 0 through 9. If no
run level is specified, the process is assumed to be valid at all run levels.
- There are three other values that appear in the runlevel field, even
though they are not true run levels: a, b, and c. Entries that have these
characters in the run level field are processed only when the telinit
command requests them to be run (regardless of the current run level of the
system). They differ from run levels in that the init command can
never enter run level a, b, or c. Also, a request for the execution of any of
these processes does not change the current run level. Furthermore, a process
started by an a, b, or c command is not killed when the init command
changes levels. They are only killed if their line in the /etc/inittab file is
marked off in the action field, their line is deleted entirely from
/etc/inittab, or the init command goes into single-user mode.
-
Action
- Tells the init command how to treat the
process specified in the process field. The following actions are recognized by
the init command:
-
respawn
- If the process does not exist, start the process. Do
not wait for its termination (continue scanning the /etc/inittab file). Restart
the process when it dies. If the process exists, do nothing and continue
scanning the /etc/inittab file.
-
wait
- When the init command enters the run level
that matches the entry's run level, start the process and wait for its
termination. All subsequent reads of the /etc/inittab file, while the
init command is in the same run level, will cause the init
command to ignore this entry.
-
once
- When the init command enters a run level that
matches the entry's run level, start the process, and do not wait for
termination. When it dies, do not restart the process. When the system enters a
new run level, and the process is still running from a previous run level
change, the program will not be restarted.
-
boot
- Process the entry only during system boot, which is
when the init command reads the /etc/inittab file during system
startup. Start the process, do not wait for its termination, and when it dies,
do not restart the process. In order for the instruction to be meaningful, the
run level should be the default or it must match the init command's
run level at boot time. This action is useful for an initialization function
following a hardware reboot of the system.
-
bootwait
- Process the entry the first time that the
init command goes from single-user to multi-user state after the
system is booted. Start the process, wait for its termination, and when it
dies, do not restart the process. If the initdefault is 2, run the process
right after boot.
-
powerfail
- Execute the process associated with this entry only
when the init command receives a power fail signal (SIGPWR).
-
powerwait
- Execute the process associated with this entry only
when the init command receives a power fail signal (SIGPWR), and wait
until it terminates before continuing to process the /etc/inittab file.
-
off
- If the process associated with this entry is currently
running, send the warning signal (SIGTERM), and wait 20 seconds before
terminating the process with the kill signal (SIGKILL). If the process is not
running, ignore this entry.
-
ondemand
- Functionally identical to respawn, except this action
applies to the a, b, or c values, not to run levels.
-
initdefault
- An entry with this action is only scanned when the
init command is initially invoked. The init command uses this
entry, if it exists, to determine which run level to enter initially. It does
this by taking the highest run level specified in the runlevel field and using
that as its initial state. If the run level field is empty, this is interpreted
as 0123456789: therefore, the init command enters run level 9.
Additionally, if the init command does not find an initdefault entry
in the /etc/inittab file, it requests an initial run level from the user at
boot time.
-
sysinit
- Entries of this type are executed before the
init command tries to access the console before login. It is expected
that this entry will only be used to initialize devices on which the
init command might try to ask the run level question. These entries
are executed and waited for before continuing.
-
Command
- A shell command to execute. The entire command field
is prefixed with exec and passed to a forked sh as sh -c exec command.
Any legal sh syntax can appear in this field. Comments can be inserted with the
# comment syntax.
The getty command writes over the output of
any commands that appear before it in the /etc/inittab file. To record the
output of these commands to the boot log, pipe their output to the alog
-tboot command.
The stdin, stdout, and stdferr file descriptors may not
be available while init is processing inittab entries. Any entries writing to
stdout or stderr may not work predictably unless they redirect their output to
a file or to /dev/console.
The following commands are the only supported method for modifying the
records in the /etc/inittab file:
-
chitab
- Changes records in the /etc/inittab file.
-
lsitab
- Lists records in the /etc/inittab file.
-
mkitab
- Adds records to the /etc/inittab file.
-
rmitab
- Removes records from the /etc/inittab file.
An example of /etc/inittab entries is shown in
Figure 8.
Figure 8: Entries in /etc/inittab
The base process entries in the /etc/initab file is
ordered as follows:
- 1 - initdefault
- 2 - sysinit
- 3 - Powerfailure Detection (powerfail)
- 4 - Multiuser check (rc)
- 5 - /etc/firstboot (fbcheck)
- 6 - System Resource Controller (srcmstr)
- 7 - Start TCP/IP daemons (rctcpip)
- 8 - Start NFS daemons (rcnfs)
- 9 - cron
- 10 - pb cleanup (piobe)
- 11 - getty for the console (cons)
The System Resource Controller (SRC) has to be started
near the beginning of the etc/inittab file since the SRC daemon is needed to
start other processes. Since NFS requires TCP/IP daemons
to run correctly, TCP/IP daemons are started ahead of the NFS daemons. The
entries in the /etc/inittab file are ordered according to dependencies, meaning
that if a process (process1) requires that another process (process2) be
present for it to operate normally, then an entry for process2 comes before an
entry for process1 in the /etc/inittab file.
3.2 Initialization
Customization and Problem Determination