Version 7 Unix: /etc listing, showing init and rc

Version 7 Unix: contents of an/etc/rc Bourne shell script

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 indirectancestor of all other processes and automatically adopts all orphaned processes. Init is started by the kernel using a hard-coded filename, and if the kernel is unable to start it, a kernel panic will result. Init is typically assigned process identifier 1.

The design of init has diverged in Unix systems such as System III and System V, from the functionality provided by the init in Research Unix and its BSD derivatives. The usage on most Linux distributions is somewhat compatible with System V, but some distributions, such as Slackware, use a BSD-style and others, such as Gentoo, have their own customized version.

Several replacement init implementations have been written with attempt to address design limitations in the standard versions. These include systemd and Upstart, the latter being used by Ubuntu^[1][2] and some other Linux distributions.^[3][4]

SysV-style[edit]

System V init examines the /etc/inittab file for an :initdefault: entry, which defines any default runlevel. If there is no default runlevel, then init dumps the user to a system console for manual entry of a runlevel.

Runlevels[edit]

The runlevels in System V describe certain states of a machine, characterized by the processes run. There are generally eight runlevels, three of which are "standard":

0. Halt

1. Single user mode (aka. S or s)

6. Reboot

Aside from these, every Unix and Unix-like system treats runlevels a little differently. The common denominator, the /etc/inittab file, defines what each runlevel does (if they do anything at all) in a given system.

Default runlevels[edit]

On the Linux distributions defaulting to runlevel 5 in the table above, runlevel 5 invokes a multiuser graphical environment running the X Window System, usually with a display manager like GDM or KDM. However, the Solaris operating system typically reserves runlevel 5 to shut down and automatically power off the machine.

On most systems users can check the current runlevel with either of the following commands:

$ runlevel (need to be root or sudo)

$ who -r

The root typically changes the current runlevel by running the telinit or init commands. The /etc/inittab file sets the default runlevel with the :initdefault: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).^{[citation needed]} 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.

BSD-style[edit]

BSD init runs the initialization shell script located in /etc/rc, then launches getty on text-based terminals or a windowing system such as X on graphical terminals under the control of /etc/ttys. There are no runlevels; the /etc/rc 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. To mitigate this, BSD variants have long supported a site-specific /etc/rc.local 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 /etc/rc.d 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.^[11] The order in which scripts are executed is determined by the rcorder script based on the requirements stated in these tags.

Replacements for init[edit]

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 I/O blocked, this can result in long delays during boot.

Various efforts have been made to replace the traditional init daemons to address this and other design problems, including:

• BootScripts in GoboLinux
• busybox-init, suited embedded operating systems, employed by OpenWrt before it was replaced with procd
• DEMONS, a modification of the init start process by KahelOS, where daemons are started only when the DE (desktop environment) started.
• eINIT, a full replacement of init designed to start processes asynchronously, but with the potential of doing it without shell scripts
• Initng, a full replacement of init designed to start processes asynchronously
• launchd, a replacement for init introduced in Mac OS X v10.4 (it launches SystemStarter to run old-style ‘rc.local‘ and SystemStarter processes)
• Mudur, an init replacement written in Python and designed to start process asynchronously in use by the Pardus Linux distribution.^[12]
• runit, a cross-platform full replacement for init with parallel starting of services
• s6, another cross-platform full replacement for init, similar to runit.
• Service Management Facility, a complete full replacement/redesign of init from the ground up in Solaris starting with Solaris 10
• systemd, a full replacement for init with parallel starting of services and other features, used by many distributions.
• SystemStarter, a process spawner started by the BSD-style init in Mac OS X prior to Mac OS X v10.4
• Upstart, a full replacement of init designed to start processes asynchronously initiated by Ubuntu.

init（为英语：initialization的简写）是 Unix 和 类Unix 系统中用来产生其它所有进程的程序。它以守护进程的方式存在，其进程号为1。

Unix 系列中(如 System III 和 System V)init的作用，和研究中的 Unix 和 BSD 派生版本相比，发生了一些变化。大多数Linux发行版是和 System V 相兼容的，但是一些发行版如Arch 和 Slackware 采用的是BSD风格，其它的如 Gentoo 是自己定制的。Ubuntu^[1][2] 和其它一些发行版现在开始采用 Upstart^[3] 来代替^[4] 传统的 init 进程。

BSD风格[编辑]

BSD init 运行存放于‘/etc/rc‘的初始化 shell 脚本，然后启动基于文本模式的终端(getty)或者基于图形界面的终端(窗口系统，如 X)。 这里没有运行模式的问题，因为文件 ‘rc‘ 决定了 init 如何执行。

优点: 简单且易于手动编辑。

缺点: 如果第三方软件需要在启动过程执行它自身的初始化脚本，它必须修改已经存在的启动脚本，一旦这种过程中有一个小错误，都将导致系统无法正常启动。

值得注意的是，现代的 BSD 派生系统一直支持使用 ‘rc.local‘ 文件的方式，它将在正常启动过程接近最后的时间以子脚本的方式来执行。这样做减少了整个系统无法启动的风险。然后，第三方软件包可以将它们独立的 start/stop 脚本安装到一个本地的 ‘rc.d‘ 目录中(通常这是由 ports collection/pkgsrc 完成的)。 FreeBSD 和 NetBSD 现在默认使用rc.d ，该目录中所有的用户启动脚本，都被分成更小的子脚本，和 SysV 类似。rcorder 通常根据在 rc.d目录中脚本之间的依赖关系来决定脚本的执行顺序。

SysV风格[编辑]

System V init 检查 ‘/etc/inittab‘ 文件中是否含有 ‘initdefault‘ 项。 这告诉 init 系统是否有一个默认运行模式。如果没有默认的运行模式，那么用户将进入系统控制台，手动决定进入何种运行模式。

优点: 灵活性强

缺陷: 比较复杂

运行模式[编辑]

System V中运行模式描述了系统各种可能的状态。通常会有 8 种运行模式，即运行模式 0 到 6 和 S 或者 s。其中运行模式 3 为"保留的"运行模式:

0. 关机

1. 单用户模式

6. 重启

除了模式 0, 1,6外, 每种 Unix 和 Unix-like 系统对运行模式的定义不太一样。通常在 /etc/inittab 文件中定义了各种运行模式的工作范围。

默认的运行模式[编辑]

上面的表中有两种Linux发行版默认的运行模式为 5，模式 5 是多用户图形环境(X Window System)，通常还包括X显示管理器。然而在Solaris操作系统中，模式 5 被保留用来执行关机和自动切断电源。

大多数操作系统的用户可以用下面的命令来判断当前的运行模式是什么:

$ runlevel
$ who -r

在 root 权限下，运行 telinit 或者 init 命令可以改变当前的运行模式。 /etc/inittab 文件中设置的默认的运行模式在 :initdefault: 项中。

跳过 init[编辑]

Linux系统中，现代的bootloader(如 LILO 或者 GRUB)，用户可以在初始化过程中最后启动的进程来取代默认的 /sbin/init。 通常是在 bootloader 环境中通过执行 init=/foo/bar命令。例如，如果执行 init=/bin/bash，启动单用户 root 的 shell 环境，无需用户密码。

BSD的变种，大多数平台， bootstrap 程序是可以被打断的，然后执行 boot -s 命令进入单用户模式。

单用户模式并不没有跳过 init，它仍然可以执行 /sbin/init，但是它将使 init 询问 exec() 将要执行的命令 (默认为 /bin/sh) 的路径，而不是采用正常的多用户启动顺序。 如果内核启动时在 /etc/ttys 文件中被标注为 "不安全" (在某些系统中，当前的"安全模式" 可能会有些变化)， 在允许这种情况(或者回退到单用户模式，如果用户执行 CTRL+D)，init 将首先询问 root 用户的密码。 如果该程序退出，内核将在多用户模式下重新执行 init。 如果系统从多用户模式切换到单用户模式，还将碰到上述的情况。

如果内核加载后， init 不能被正常启动， 这将导致 panic 错误，此时系统将不可使用。想要通过 init 自身来改变 init 的路径，不同的版本情况不太一样(NetBSD中可执行 boot -a ; FreeBSD中利用 init_path 命令装载变量)。

其他风格[编辑]

很多人一直努力地从某些方面改进传统的 init 守护进程，使它变得更完善。下面列出的是一些改进，没有特别的顺序:

• SystemStarter, 用来替代 launchd — Apple Mac OS X开启进程
• Initng, 完全代替 init ，可以异步开启进程
• Upstart, 完全代替 init ，可以异步开启进程 由Ubuntu使用
• Service Management Facility, 完全代替/重新设计 Solaris 启动 Solaris 10
• runit, 跨平台的完全代替 init 可以并行启动服务
• BootScripts, GoboLinux
• Mudur, 用 Python 写成的 init 替代品， 可以异步开启进程，Pardus Linux 发行版
• systemd, 完全替代init，可并行启动服务，并能减少在shell上的系统开销，为Fedora所使用

下面列出的项目还没有大范围的使用:

• eINIT, 完全代替 init ，可以异步开启进程，但是完成这个过程可以不使用 shell 脚本
• svscan 来自 daemontools 被用作 1 号进程 - 似乎将被 runit 替代
• cinit
• twsinit, 部分用 x86 汇编写成， 只是用来证明一种概念
• minit
• OpenRC

Upstart

Original author(s)	Scott James Remnant
Developer(s)	Canonical Ltd.
Initial release	August 24, 2006; 7 years ago
Stable release	1.12.1[1] / March 11, 2014; 2 months ago
Written in	C
Operating system	Linux
Type	Init daemon
License	GPLv2
Website	upstart.ubuntu.com

Upstart is an event-based replacement for the traditional init daemon – the method by which several Unix-likecomputer operating systems perform tasks when the computer is started. It was written by Scott James Remnant, a former employee of Canonical Ltd.

Rationale[edit]

The traditional init process was originally only responsible for bringing the computer into a normal running state after power-on, or gracefully shutting down services prior to shutdown. As a result, the design is strictlysynchronous, blocking future tasks until the current one has completed. Its tasks must also be defined in advance, as they are limited to this prep or cleanup function. This leaves it unable to handle various non-startup-tasks on a modern desktop computer elegantly, including:

• The addition or removal of USB pen drives and other portable storage / network devices while the machine is running
• The discovery and scanning of new storage devices, without locking the system, especially when a disk may not even power on until it is scanned
• The loading of firmware for a device, which may need to occur after it is detected but before it is usable

Upstart‘s event-driven model allows it to respond to events asynchronously as they are generated.^[2]

Design[edit]

Upstart operates asynchronously; it handles starting of the tasks and services during boot and stopping them during shutdown, and also supervises the tasks and services while the system is running.

Easy transition and perfect backwards compatibility with sysvinit were the explicit design goals;^[3] accordingly, Upstart can run unmodified sysvinit scripts. In this way it differs from most other init replacements (beside systemd and OpenRC), which usually assume and require complete transition to run properly, and do not support a mixed environment of traditional and new startup methods.^[4]

Upstart allows for extensions to its event model through the use of initctl to input custom, single events, or event bridges to integrate many or more-complicated events.^[5] By default, Upstart includes bridges for socket, dbus, udev, file, and dconf events; additionally, more bridges (for example, a Mach ports bridge, or a devd (found on FreeBSD systems) bridge) are possible.^[6]

Adoption[edit]

Linux distributions and other operating systems based on the Linux kernel which use Upstart as the default init system:

• Upstart was first included in Ubuntu in the 6.10 (Edgy Eft) release in late 2006, replacing sysvinit. Ubuntu 9.10 (Karmic Koala) introduced native Upstart bootup as of Alpha 6.^[7] In turn, after the Debian project decided to adopt systemd on a future release in 2014, Mark Shuttleworth announced that Ubuntu would begin plans to migrate to systemd itself to maintain consistency with upstream.^[8]
• Upstart is used in Google‘s Chrome OS.^[9]

Linux distributions that support or have supported Upstart to some extent, but moved away since or no longer use it as their default init system:

• Debian decided that systemd will be the default init system beginning with the jessie release,^[10] after considering switching to Upstart.^[11]
• In Fedora 9, Upstart replaced sysvinit, however, systemd replaced Upstart in the Fedora 15 release.^[12][13]
• Red Hat includes Upstart in their Red Hat Enterprise Linux 6 release.^[14] As a result, it is also used by RHEL 6 variants such as CentOS, Scientific Linux, and Oracle Linux. For RHEL 7, systemd will be used.^[15][16]
• openSUSE included Upstart in version 11.3 Milestone 4, but not as default.^[17] systemd replaced Upstart, as the default init system in openSUSE 12.1.^[18]
• Upstart is used in HP‘s webOS for the Palm Pre, Palm Pixi (both before Palm was bought out by HP), HP Veer, and HP Pre 3 smart phones, along with the HP TouchPad tablet.^[19]
• Upstart replaced the sysvinit in Maemo 5 for Nokia Internet tablets^[20] and was retained for MeeGo on the N9 and N950 handsets despite MeeGo‘s transition to systemd after merging with Moblin.^{[citation needed]}

systemd is a system management daemon designed exclusively for the Linux kernel API. For systems using it, it is the first process which is executed in user space during the Linux startup process. Therefore, systemd serves as the root of the user space‘s process tree. The name systemd adheres to the Unix convention of making daemons easier to distinguish by having letter d as the last one in their actual filenames.^[5]

Overview[edit]

Systemd was developed for Linux to replace the init system inherited from UNIX System V and Berkeley Software Distribution (BSD) operating systems. Like init, systemd is a daemon that manages other daemons. All daemons, including systemd, are background processes. Systemd is the first daemon to start (during booting) and the last daemon to terminate (during shutdown).

Lennart Poettering and Kay Sievers, the software engineers who initially developed systemd,^[1] sought to surpass the efficiency of the init daemon in several ways. They wanted to improve the software framework for expressing dependencies; to allow more processing to be done concurrently or in parallel during systembooting; and to reduce the computational overhead of the shell.

Systemd is published as free and open-source software under the terms of the GNU Lesser General Public License version 2.1 or later.^[4]

Software architecture[edit]

systemd components

Unified-hierarchy cgroups will be accessible exclusively by systemd

Systemd‘s initialization instructions for each daemon are recorded in a declarative configuration file rather than a shell script. For inter-process communication, systemd makes Unix domain sockets and D-Bus available to the running daemons. Because systemd tracks processes using Linux cgroups instead of process identifiers(PIDs), daemons cannot "escape" systemd; not even by double-forking. Systemd is also capable of aggressive parallelization.

Among systemd‘s auxiliary features are a cron-like job scheduler called systemd Calendar Timers, and an eventlogging subsystem called journal.^[6] The system administrator may choose whether to log system events with systemd or syslog. Systemd‘s logfile is a binary file. The state of systemd itself can be preserved in asnapshot for future recall.

In April 2012, the source tree for udev (a device manager for the Linux kernel, which handles the /devdirectory and all user space actions when adding/removing devices, including firmware loading) was merged into systemd.^[7]

Systemd provides a replacement for sysvinit, pm-utils, inetd, acpid, syslog, watchdog, cron and atd. Also, it has an integrated login manager called systemd-logind, which offers multiseat improvements and replaces ConsoleKit, which is no longer maintained.^[8][9]

All available userspace utility programs for systemd and their man pages are currently documented at the project‘s official page.^[10]

In version 209, networkd was integrated, which provides abilities for systemd to perform various network configurations; as of this version, support is limited to statically assigned addresses and basic support forbridging configuration.^{[11][12][13][14][15]}

Since version 205, systemd offers ControlGroupInterface, an API to the Linux kernel cgroups.^[16] The Linux kernel cgroups are adapted to support kernfs,^[17] and are being modified to support a unified hierarchy.^[18]

GNOME integration[edit]

In the interest of enhancing the interoperability between systemd and GNOME desktop environment, systemd coauthor Lennart Poettering asked the GNOME Project to consider making systemd an external dependency of GNOME 3.2, so those two projects become better integrated, with GNOME using operations offered by systemd for various tasks.^[19]

In November 2012, the GNOME Project concluded that basic GNOME functionality should not rely on systemd.^[20] However, in contradiction of this statement, GNOME 3.8 introduced a de facto dependency on systemd by introducing session management behaviors which depend on how systemd operates. While the developers of Gentooattempted to adapt these changes in OpenRC, the implementation contained too many bugs, causing the distribution to mark systemd as a dependency of GNOME.^[21][22]

At the same time, GNOME is pushing further integration of systemd.^[23] For Mutter version 3.13.2, mutter-launch was replaced with logind integration.^[24]

Controversy[edit]

Adoption of systemd has been controversial at times. Articles run in Linux Advocates have characterized systemd as "the new PulseAudio," and as "an accident waiting to happen."^[25][26] One Fuduntu contributor is quoted as stating that systemd has limited software choice:^[25]

Systemd, whether by design, or circumstance, is largely becoming non-optional. Inclusion of core technologies such as dbus and udev are reducing choice for linux users and developers, rather than expanding them—which is the very antithesis of the idea of Free/Open Source software.

In a 2012 interview, Slackware‘s founder Patrick Volkerding also expressed reservations about the systemd architecture:^[27]

Concerning systemd, I do like the idea of a faster boot time (obviously), but I also like controlling the startup of the system with shell scriptsthat are readable, and I‘m guessing that‘s what most Slackware users prefer too. I don‘t spend all day rebooting my machine, and having looked at systemd config files it seems to me a very foreign way of controlling a system to me, and attempting to control services, sockets, devices, mounts, etc., all within one daemon flies in the face of the UNIX concept of doing one thing and doing it well.

Eric S. Raymond declined to comment on systemd at first, but stated, "I‘m aware there’s a controversy."^[28] Then in a March 2014 interview on Slashdot, he expressed some concerns about the goals and architecture of systemd:^[29]

I want to study it carefully because I‘m a bit troubled by what I hear about the feature set and the goals. From that, I fear it may be one of those projects that is teetering right at the edge of manageable complexity – OK as long as an architect with a strong sense of design discipline is running things, but very prone to mission creep and bloat and likely to turn into a nasty hairball over the longer term.

Adoption[edit]

In May 2011, Fedora became the first major Linux distribution to enable systemd by default.^[30] As of October 2013, Slackware does not support or use systemd, but Slackware‘s lead Patrick Volkerding has not ruled out the possibility for switching to it.^[31]