init(M)

init, telinit -- signal the init process

Syntax

/etc/init [ 0123456SsQqabc ]

/bin/telinit [ 0123456SsQqabc ]

Description

The init process (PID 1) is a general process spawner created at boot time. Its primary role is to create processes from information stored in the file /etc/inittab (see inittab(F) for further details).

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 are defined in /etc/inittab. init can be in one of the run-levels: 0 through 6 or S. (Run-levels S and s are identical.)

root can use either init or telinit to change the operating system's run-level by signaling the original init process (PID 1). (Note that telinit is a link to init.)

If a 0 through 6 is entered, init enters the corresponding run-level. Note that the run-levels 0, 1, 5, and 6 are reserved states for shutting the system down; run-levels 2, 3, and 4 are available as normal operating states.

If the file /etc/default/boot (see boot(F)) contains the string MAPKEY=YES, init invokes 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. For additional information on keywords, see bootstring(HW) and boot(HW).

init and telinit accept one of the following arguments:

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.
Note that init 0 should not be used if you have a USB keyboard attached to the console. During an init 0, the USB stack gets shut down and the system then waits for a keyboard keypress interrupt before rebooting. Since USB is gone, there's no way for a keypress on the USB keyboard to get serviced, and the system does not respond. If this occurs, you must either press the hardware reset button or power cycle the system.
1: Put the system in single-user mode. Unmount all file systems except the root filesystem. All user processes are killed except those connected to the console. It is recommended that this state 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 multiuser mode.
3, 4: Are available to be defined as alternative multiuser environment configurations. They are not necessary for system operation and are not normally used.
5: Stop the UNIX system and go to the firmware monitor.
6: Stop the UNIX system and reboot to the run-level 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 ``Limitations'' 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 actions occur:

init 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 single-user mode, 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.
Note that if the shell is terminated (via an end-of-file), init will only reinitialize to single-user mode if the /etc/inittab file does not exist.

On entering single-user mode for the first time since the system last booted, init only runs entries in /etc/inittab (see inittab(F)) which have sysinit set in their action field.

If init enters a run-level other than single-user mode for the first time since the system last boooted, it runs entries in /etc/inittab which specify this run-level (or none) in their rstate field and which have boot and bootwait set in their action field. 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 the new 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. (For more information about /etc/initscript, see initscript(ADM).)

After init has spawned all of the processes specified by /etc/inittab, it waits for:

one of its descendant processes to die,
a powerfail signal,
a signal from another init or telinit process to change the system's run-level, or possibility of SLEEPTIME wait,
SLEEPTIME seconds to elapse (unless this has been set to the default of zero). See boot(HW) for further details.

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 four 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 single-user mode to another run-level, 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 single-user mode 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 power failure signal (SIGPWR), it scans /etc/inittab for special entries of the type powerfail or powerwait. These entries are invoked (if the run-level permits this) before any further processing takes place. In this way init can perform various cleanup and recording functions during the powerdown of the operating system.

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.

Limitations

Only root can run init and telinit.

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, as described in the ``Limitations'' 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 should exist. /etc/initscript tries to execute this file to set the correct TZ variable for the system.

Files

/etc/default/boot
/etc/inittab
/etc/utmp
/etc/wtmp
/etc/ioctl.syscon
/etc/initscript
/dev/console
/dev/contty

Standards conformance

init is conformant with:

AT&T SVID Issue 2.

telinit is not part of any currently supported standard.