Init

In Unix-based computer operating systems, init (short for "initialization") is the first process started during booting of the computer system. Init is a daemon process that continues running until the system is shut down. It is the direct or indirect ancestor of all other processes and automatically adopts all orphaned processes. Init is started by the kernel during the booting process; a kernel panic will occur if the kernel is unable to start it. Init is typically assigned process identifier 1.
In Unix systems such as System III and System V, the design of init has diverged from the functionality provided by the init in Research Unix and its BSD derivatives. Up until recently, most Linux distributions employed a traditional init that is somewhat compatible with System V, while some distributions such as Slackware use BSD-style startup scripts, and others such as Gentoo have their own customized versions.
Since then, several additional init implementations have been created, attempting to address design limitations in the traditional versions. These include launchd, the Service Management Facility, systemd, Runit and OpenRC.
Research Unix-style/BSD-style.
Research Unix init ran the initialization shell script located at codice_1, then launched getty on terminals under the control of codice_2. There are no runlevels; the codice_1 file determines what programs are run by init. The advantage of this system is that it is simple and easy to edit manually. However, new software added to the system may require changes to existing files that risk producing an unbootable system.
BSD init was, prior to 4.3BSD, the same as Research UNIX's init; in 4.3BSD, it added support for running a windowing system such as X on graphical terminals under the control of codice_2. To remove the requirement to edit codice_1, BSD variants have long supported a site-specific codice_6 file that is run in a sub-shell near the end of the boot sequence.
A fully modular system was introduced with NetBSD 1.5 and ported to FreeBSD 5.0 and successors. This system executes scripts in the codice_7 directory. Unlike System V's script ordering, which is derived from the filename of each script, this system uses explicit dependency tags placed within each script. The order in which scripts are executed is determined by the "rcorder" utility based on the requirements stated in these tags.
SysV-style.
When compared to its predecessors, AT&T's UNIX System III introduced a new style of system startup configuration, which survived (with modifications) into UNIX System V and is therefore called the "SysV-style init".
At any moment, a running System V is in one of the predetermined number of states, called "runlevels". At least one runlevel is the normal operating state of the system; typically, other runlevels represent single-user mode (used for repairing a faulty system), system shutdown, and various other states. Switching from one runlevel to another causes a per-runlevel set of scripts to be run, which typically mount filesystems, start or stop daemons, start or stop the X Window System, shutdown the machine, etc.
Runlevels.
The runlevels in System V describe certain states of a machine, characterized by the processes and daemons running in each of them. In general, there are seven runlevels, out of which three runlevels are considered "standard" as they are essential to the operation of a system:
Aside from these standard ones, Unix and Unix-like systems treat runlevels somewhat differently. The common denominator, the codice_8 file, defines what each configured runlevel does in a given system.
Default runlevels.
On Linux distributions defaulting to runlevel 5 in the table on the right, runlevel 5 invokes a multiuser graphical environment running the X Window System, usually with a display manager like GDM or KDM. However, the Solaris and illumos operating systems typically reserve runlevel 5 to shut down and automatically power off the machine.
On most systems, all users can check the current runlevel with either the codice_9 or codice_10 command. The root user typically changes the current runlevel by running the codice_11 or codice_12 commands. The codice_8 file sets the default runlevel with the codice_14 entry.
On Unix systems, changing the runlevel is achieved by starting only the missing services (as each level defines only those that are started / stopped). For example, changing a system from runlevel 3 to 4 might only start the local X server. Going back to runlevel 3, it would be stopped again.
Other implementations.
Traditionally, one of the major drawbacks of init is that it starts tasks serially, waiting for each to finish loading before moving on to the next. When startup processes end up Input/output (I/O) blocked, this can result in long delays during boot. Speeding up I/O, e.g. by using SSDs, may shorten the delays but it does not address the root cause.
Various efforts have been made to replace the traditional init daemons to address this and other design problems, including:
, systemd has been adopted by most major Linux distributions.