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 original 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. 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. 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. First, init looks in /etc/inittab for the initdefault entry (see inittab(4)). If there is one, init uses 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 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(4)). 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 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.
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. 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(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 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(1)). 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.
init scans /etc/default/boot for NPROC=nnn. If it is found, the process table size is set to nnn, otherwise the process table size is set to a reasonable default value. /etc/default/boot is also scanned for the PANICBOOT keyword. If init finds PANICBOOT=YES, it will configure the system to reboot after a system panic. By default, the system does not reboot after a system panic.
telinit
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/inittab
/etc/utmp
/etc/wtmp
/etc/ioctl.syscon
/etc/default/boot
/dev/console
/dev/contty
SEE ALSO
getty(1M), login(1), sh(1), shutdown(1M), stty(1), sulogin(1M), who(1).
kill(2).
gettydefs(4), inittab(4), utmp(4).
termio(7).
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 consuming 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.
WARNINGS
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. Do not change to state 1, S, or s if the system console is configured as No Console. To change to any other states when the console is No Console, /dev/console must be redirected to the init command. For example, to change to state 0 when the console setting is No Console, type:
init 0 < /dev/console
The change to /etc/gettydefs described in the WARNINGS section of the gettydefs(4) 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 should exist.
ADDED VALUE
This entry, supplied by SunSoft, Inc., contains enhancements to UNIX System V.
\*U — Version 1.0