init(1M) SYSTEM ADMINISTRATION COMMANDS init(1M)
NAME
init, telinit - process control initialization
SYNOPSIS
/etc/init [0123456SsQqabc]
/etc/telinit [0123456SsQqabc]
DESCRIPTION
init
init is a general process spawner. Its primary role is to
create processes from information stored in the file
/etc/inittab [see inittab(4)].
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 ori-
ginal init spawned by the operating system when the system
was booted, telling it which run level to change to.
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.
1 put the system in system administrator mode.
All file systems are mounted. Only a small set
of essential kernel processes are left running.
This mode is for administrative tasks such as
installing optional utility packages. All files
are accessible and no users are logged in on the
system.
2 put the system in multi-user mode. All multi-
user environment terminal processes and daemons
are spawned. This state is commonly referred to
as the multi-user state.
3 start the remote file sharing processes and dae-
mons. Mount and advertise remote resources.
Run level 3 extends multi-user mode and is known
as the remote-file-sharing state.
4 is available to be defined as an alternative
multi-user environment configuration. It is not
necessary for system operation and is usually
1
init(1M) SYSTEM ADMINISTRATION COMMANDS init(1M)
not used.
5 Stop the UNIX system and go to the firmware mon-
itor.
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 cer-
tain 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. This is the only run level that
doesn't require the existence of a properly for-
matted /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 comes up to S or s, file systems
for users' files are not mounted and only essen-
tial kernel processes are running. When the
system comes down to S or s, all mounted file
systems remain mounted, and all processes
started by init that should only be running in
multi-user mode are killed. In addition, any
process that has a utmp entry will be killed.
This last condition insures that all port moni-
tors started by the SAC are killed and all ser-
vices started by these port monitors, including
ttymon login services, are killed. Other
processes not started directly by init will
remain running. For example, cron remains run-
ning.
When a UNIX system is booted, init is invoked and the fol-
lowing occurs. First, init looks in /etc/inittab for the
initdefault entry [see inittab(4)]. If there is one, init
will usually use the run level specified in that entry as
the initial run level to enter. If there is no initdefault
entry in /etc/inittab, init requests that the user enter a
run level from the virtual system console. If an S or s is
entered, init goes to the single-user state. In the
single-user state the virtual console terminal is assigned
to the user's terminal and is opened for reading and writ-
ing. The command /sbin/su is invoked and a message is gen-
erated on the physical console saying where the virtual
2
init(1M) SYSTEM ADMINISTRATION COMMANDS init(1M)
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. Run levels 0, 5, and 6 are reserved states for
shutting the system down. Run levels 2, 3, and 4 are avail-
able as multi-user 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 init-
tab(4)]. These entries are performed before any other pro-
cessing 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 file systems, 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.
To spawn each process in /etc/inittab, init reads each entry
and for each entry that should be respawned, it forks a
child process. After it has spawned all of the processes
specified by /etc/inittab, init waits for one of its descen-
dant 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, 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(2) 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 warn-
ing signal (SIGTERM) to all processes that are undefined in
the target run level. init waits five seconds before forci-
bly terminating these processes via the kill signal (SIG-
KILL).
When init receives a signal telling it that a process it
spawned has died, it records the fact and the reason it died
in /var/adm/utmp and /var/adm/wtmp if it exists [see
3
init(1M) SYSTEM ADMINISTRATION COMMANDS init(1M)
who(1)]. A history of the processes spawned is kept in
/var/adm/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.
telinit
telinit, which is linked to /etc/init, is used to direct the
actions of init. It takes a one-character argument and sig-
nals init to take the appropriate action.
FILES
/etc/inittab
/var/adm/utmp
/var/adm/wtmp
/etc/ioctl.syscon
/dev/console
SEE ALSO
ttymon(1M), shutdown(1M), inittab(4), utmp(4), utmpx(4),
termio(7).
login(1), sh(1), stty(1), who(1) in the User's Reference
Manual.
kill(2) in the Programmer's Reference Manual.
DIAGNOSTICS
If init finds that it is respawning an entry from
/etc/inittab more than ten times in two 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 five
minutes has elapsed or it receives a signal from a user-
spawned init or 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 a privileged 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
4
init(1M) SYSTEM ADMINISTRATION COMMANDS init(1M)
than the initdefault. If a default state is not specified
in the initdefault entry in /etc/inittab, state 6 is
entered. Consequently, the system will loop, that is, it
will go to firmware and reboot continuously. If the utmp
file cannot be created when booting the system, the system
will boot to state ``s'' regardless of the state specified
in the initdefault entry in /etc/inittab. This can happen
if the /var filesystem is not accessible.
5