INIT(M) UNIX System V
Name
init, telinit - process control initialization
Syntax
/etc/init [0123456SsQqabc]
/bin/telinit [0123456SsQqabc]
Description
init is a general process spawner. Its primary role is to
create processes from information stored in the file
/etc/inittab [see inittab(F)].
At any given time, the system is in one of eight possible
run levels. A run level is a software configuration of the
system under which only a selected group of processes exist.
The processes spawned by init for each of these run levels
is defined in /etc/inittab. init can be in one of eight run
levels, 0-6 and S or s (run levels S and s are identical).
The run level changes when a privileged user runs /etc/init.
This user-spawned init sends appropriate signals to the
original init spawned by the operating system when the
system was booted, telling it which run level to change to.
If the file /etc/default/boot contains the string
MAPKEY=YES, init invokes the mapkey program (see mapkey(M))
to map the console keyboard. If the call to mapkey
succeeds, the console is set to 8-bits no parity. If the
call fails, and the string SERIAL8=YES appears in
/etc/default/boot, a serial console device is assumed and
set to 8-bits no parity.
The following are the arguments to init:
0 shut the machine down so it is safe to remove
the power. Have the machine remove power if it
can. This state can be executed only from the
console.
1 put the system in single-user mode. Unmount all
file systems except root. All user processes
are killed except those connected to the
console. This state can be executed only from
the console.
2 put the system in multiuser mode. All multiuser
environment terminal processes and daemons are
spawned. This state is commonly referred to as
the multiuser state.
3 start the remote file sharing processes and
daemons. Mount and advertise remote resources.
Run level 3 extends multiuser mode and is known
as the remote-file-sharing state.
4 is available to be defined as an alternative
multiuser environment configuration. It is not
necessary for system operation and is usually
not used.
5 Stop the UNIX system and go to the firmware
monitor.
6 Stop the UNIX system and reboot to the state
defined by the initdefault entry in
/etc/inittab.
a,b,c process only those /etc/inittab entries having
the a, b or c run level set. These are pseudo-
states, which may be defined to run certain
commands, but which do not cause the current run
level to change.
Q,q re-examine /etc/inittab.
S,s enter single-user mode. When this occurs, the
terminal which executed this command becomes the
system console (see Notes for more information
about console device assignment). This is the
only run level that doesn't require the
existence of a properly formatted /etc/inittab
file. If this file does not exist, then by
default the only legal run level that init can
enter is the single-user mode. When the system
enters S or s, all mounted file systems remain
mounted and only processes spawned by init are
killed.
When a
UNIX system is booted, init is invoked and the following
occurs. init first looks in /etc/default/boot to determine
if autoboot on panic is desired. init looks to see if
DEFAULT_LEVEL=N is specified in /etc/default/boot. If it is,
then N is the default level, otherwise, the user is prompted
to see if they wish to go to multiuser or system maintenance
mode (single-user mode). In the single-user state, the
virtual console terminal is assigned to the user's terminal
and is opened for reading and writing. The sulogin command,
which requires the user to enter the root password, is
invoked and a message is generated on the physical console
saying where the virtual console has been relocated. Use
either init or telinit to signal init to change the run
level of the system. Note that if the shell is terminated
(via an end-of-file), init will only re-initialize to the
single-user state if the /etc/inittab file does not exist.
If a 0 through 6 is entered, init enters the corresponding
run level. Note that, on the 80386 computer, the run levels
0, 1, 5, and 6 are reserved states for shutting the system
down; the run levels 2, 3, and 4 are available as normal
operating states.
On your computer, the run-levels 0 and 1 are reserved states
for shutting the system down, and run-levels 2, 3, and 4 are
available as normal operating states.
If this is the first time since power up that init has
entered a run level other than single-user state, init first
scans /etc/inittab for boot and bootwait entries [see
inittab(F)]. These entries are performed before any other
processing of /etc/inittab takes place, providing that the
run level entered matches that of the entry. In this way,
any special initialization of the operating system, such as
mounting filesystems, can take place before users are
allowed onto the system. init then scans /etc/inittab and
executes all other entries that are to be processed for that
run level.
In a multiuser environment, /etc/inittab is set up so that
init will create a getty process for each terminal that the
administrator sets up to respawn.
To spawn each process in /etc/inittab, init reads each entry
and for each entry that should be respawned, it forks a
child process. init spawns each process by forking a shell
to run the job in. To set up the environment for this
shell, init uses the /etc/initscript file which contains the
definitions of some global variables, for example, TZ, HZ,
and PATH. After it has spawned all of the processes
specified by /etc/inittab, init waits for one of its
descendant processes to die, a powerfail signal, or a signal
from another init or telinit process to change the system's
run level. When one of these conditions occurs, init re-
examines /etc/inittab. New entries can be added to
/etc/inittab at any time; however, init still waits for one
of the above three conditions to occur before re-examining
/etc/inittab. To get around this, an init Q or init q
command wakes init to re-examine /etc/inittab immediately.
When init comes up at boot time and whenever the system
changes from the single-user state to another run state,
init sets the ioctl(S) states of the virtual console to
those modes saved in the file /etc/ioctl.syscon. This file
is written by init whenever the single-user state is
entered.
When a run level change request is made, init sends the
warning signal (SIGTERM) to all processes that are undefined
in the target run level. init waits 5 seconds before
forcibly terminating these processes via the kill signal
(SIGKILL).
The shell running on each terminal will terminate when the
user types an end-of-file or hangs up. When init receives a
signal telling it that a process it spawned has died, it
records the fact and the reason it died in /etc/utmp and
/etc/wtmp if it exists [see who(C)]. A history of the
processes spawned is kept in /etc/wtmp.
If init receives a powerfail signal (SIGPWR) it scans
/etc/inittab for special entries of the type powerfail and
powerwait. These entries are invoked (if the run levels
permit) before any further processing takes place. In this
way init can perform various cleanup and recording functions
during the powerdown of the operating system. Note that in
the single-user states, S and s, only powerfail and
powerwait entries are executed. telinit, which is linked to
/etc/init, is used to direct the actions of init. It takes
a one-character argument and signals init to take the
appropriate action.
Files
/etc/default/boot
/etc/inittab
/etc/utmp
/etc/wtmp
/etc/ioctl.syscon
/etc/initscript
/dev/console
/dev/contty
See Also
disable(C), enable(C), login(M), sh(C), stty(C), who(C),
getty(M), shutdown(M), sulogin(ADM), termio(HW), kill(S),
gettydefs(F), inittab(F), utmp(F)
Diagnostics
If init finds that it is respawning an entry from
/etc/inittab more than 10 times in 2 minutes, it will assume
that there is an error in the command string in the entry,
and generate an error message on the system console. It
will then refuse to respawn this entry until either 5
minutes has elapsed or it receives a signal from a user-
spawned init (telinit). This prevents init from eating up
system resources when someone makes a typographical error in
the inittab file or a program is removed that is referenced
in /etc/inittab.
When attempting to boot the system, failure of init to
prompt for a new run level may be because the virtual system
console is linked to a device other than the physical system
console.
Notes
init and telinit can be run only by someone who is super-
user.
The S or s state must not be used indiscriminately in the
/etc/inittab file. A good rule to follow when modifying
this file is to avoid adding this state to any line other
than the initdefault.
The assignment of the console device may seem confusing at
first. Whenever the system is rebooted, the first boot up
messages will be displayed on the ``normal'' system console
(tty01), then the prompt for going multiuser will be
displayed on the the tty from which init S was last invoked,
which could be any tty on the system. The system console
device (/dev/syscon) remains linked to the tty from which
the last init S is invoked. Rebooting the system does NOT
reset this to tty01.
If the /etc/initscript file is not present, init will print
a warning on the console and spawn the job without setting
up the global environment.
The change to /etc/gettydefs described in the Notes section
of the gettydefs(F) manual page will permit terminals to
pass 8 bits to the system as long as the system is in
multiuser state (run level greater than 1). When the system
changes to single-user state, the getty is killed and the
terminal attributes are lost. To permit a terminal to pass
8 bits to the system in single-user state, after you are in
single-user state, type:
stty -istrip cs8
The /etc/TIMEZONE file must exist. /etc/initscript executes
this file to set the correct TZ variable for the system.
Standards Conformance
init is conformant with:
AT&T SVID Issue 2, Select Code 307-127.
(printed 4/27/90) INIT(M)