Init

Last updated
Version 7 Unix: .mw-parser-output .monospaced{font-family:monospace,monospace} /etc listing, showing init and rc Version 7 UNIX SIMH PDP11 Etc.png
Version 7 Unix: /etc listing, showing init and rc
Version 7 Unix: contents of an /etc/rc Bourne shell script Version 7 UNIX SIMH PDP11 Etc Rc.png
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 operating 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, or it should die for any reason. Init is typically assigned process identifier 1.

Contents

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 the early 2010s, [1] [ failed verification ] most Linux distributions employed a traditional init that was somewhat compatible with System V, while some distributions such as Slackware use BSD-style startup scripts, and others still 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 runs the initialization shell script located at /etc/rc, [2] then launches getty on terminals under the control of /etc/ttys. [3] 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.

BSD init was, prior to 4.3BSD, the same as Research UNIX's init; [4] [5] in 4.3BSD, it added support for running a windowing system such as X on graphical terminals under the control of /etc/ttys. [6] [7] To remove the requirement to edit /etc/rc, 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. [8] The order in which scripts are executed is determined by the rcorder utility based on the requirements stated in these tags.

SysV-style

sysv-rc-conf, a TUI utility that selects which SysV-style init scripts will be run in each runlevel Sysv-rc-conf.png
sysv-rc-conf, a TUI utility that selects which SysV-style init scripts will be run in each runlevel

When compared to its predecessors, AT&T's UNIX System III introduced a new style of system startup configuration, [9] 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:

  1. Turn off
  2. Single-user mode (also known as S or s)
  3. Reboot

Aside from these standard ones, Unix and Unix-like systems treat runlevels somewhat differently. The common denominator, the /etc/inittab file, defines what each configured runlevel does in a given system.

Default runlevels

Operating systemDefault runlevel
AIX 2
antiX 5
Gentoo Linux 3 [10]
HP-UX 3 (console/server/multiuser) or 4 (graphical)
Linux From Scratch 3
Slackware Linux 3
Solaris / illumos 3 [11]
UNIX System V Releases 3.x, 4.x2
UnixWare 7.x3

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 runlevel or who -r command. [12] The root user 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.

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:

As of February 2019, systemd has been adopted by most major Linux distributions. [23]

See also

Related Research Articles

<span class="mw-page-title-main">Unix shell</span> Command-line interpreter for Unix operating system

A Unix shell is a command-line interpreter or shell that provides a command line user interface for Unix-like operating systems. The shell is both an interactive command language and a scripting language, and is used by the operating system to control the execution of the system using shell scripts.

The Filesystem Hierarchy Standard (FHS) is a reference describing the conventions used for the layout of Unix-like systems. It has been made popular by its use in Linux distributions, but it is used by other Unix-like systems as well. It is maintained by the Linux Foundation. The latest version is 3.0, released on 3 June 2015.

A child process in computing is a process created by another process. This technique pertains to multitasking operating systems, and is sometimes called a subprocess or traditionally a subtask.

<span class="mw-page-title-main">Daemon (computing)</span> Computer program that runs as a background process

In multitasking computer operating systems, a daemon is a computer program that runs as a background process, rather than being under the direct control of an interactive user. Traditionally, the process names of a daemon end with the letter d, for clarification that the process is in fact a daemon, and for differentiation between a daemon and a normal computer program. For example, syslogd is a daemon that implements system logging facility, and sshd is a daemon that serves incoming SSH connections.

chroot Operation that changes the apparent root directory in Unix-like systems

chroot is an operation on Unix and Unix-like operating systems that changes the apparent root directory for the current running process and its children. A program that is run in such a modified environment cannot name files outside the designated directory tree. The term "chroot" may refer to the chroot(2) system call or the chroot(8) wrapper program. The modified environment is called a chroot jail.

A runlevel is a mode of operation in the computer operating systems that implements Unix System V-style initialization. Conventionally, seven runlevels exist, numbered from zero to six. S is sometimes used as a synonym for one of the levels. Only one runlevel is executed on startup; run levels are not executed one after another.

udev is a device manager for the Linux kernel. As the successor of devfsd and hotplug, udev primarily manages device nodes in the /dev directory. At the same time, udev also handles all user space events raised when hardware devices are added into the system or removed from it, including firmware loading as required by certain devices.

Unix-like operating systems identify a user by a value called a user identifier, often abbreviated to user ID or UID. The UID, along with the group identifier (GID) and other access control criteria, is used to determine which system resources a user can access. The password file maps textual user names to UIDs. UIDs are stored in the inodes of the Unix file system, running processes, tar archives, and the now-obsolete Network Information Service. In POSIX-compliant environments, the shell command id gives the current user's UID, as well as more information such as the user name, primary user group and group identifier (GID).

launchd is an init and operating system service management daemon created by Apple Inc. as part of macOS to replace its BSD-style init and SystemStarter. There have been efforts to port launchd to FreeBSD and derived systems.

Service Management Facility (SMF) is a feature of the Solaris operating system as of version 10 and OpenSolaris-descendant illumos with its illumos distributions, that creates a supported, unified model for services and service management on each Solaris or illumos system and replaces init.d scripts. SMF introduces:

Upstart is a discontinued event-based replacement for the traditional init daemon—the method by which several Unix-like computer operating systems perform tasks when the computer is started. It was written by Scott James Remnant, a former employee of Canonical Ltd. In 2014, Upstart was placed in maintenance mode, and other init daemons, such as systemd, were recommended in place of Upstart. Ubuntu moved away from Upstart with the release of version 15.04 in favor of migrating to systemd. As of June 2024, there have been no updates released for Upstart since September 2014.

Single-user mode is a mode in which a multiuser computer operating system boots into a single superuser. It is mainly used for maintenance of multi-user environments such as network servers. Some tasks may require exclusive access to shared resources, for example running fsck on a network share. This mode can also be used for security purposes – network services are not run, eliminating the possibility of outside interference. On some systems a lost superuser password can be changed by switching to single-user mode, but not asking for the password in such circumstances is viewed as a security vulnerability.

The Linux booting process involves multiple stages and is in many ways similar to the BSD and other Unix-style boot processes, from which it derives. Although the Linux booting process depends very much on the computer architecture, those architectures share similar stages and software components, including system startup, bootloader execution, loading and startup of a Linux kernel image, and execution of various startup scripts and daemons. Those are grouped into 4 steps: system startup, bootloader stage, kernel stage, and init process. When a Linux system is powered up or reset, its processor will execute a specific firmware/program for system initialization, such as the power-on self-test, invoking the reset vector to start a program at a known address in flash/ROM, then load the bootloader into RAM for later execution. In IBM PC–compatible personal computers (PCs), this firmware/program is either a BIOS or a UEFI monitor, and is stored in the mainboard. In embedded Linux systems, this firmware/program is called boot ROM. After being loaded into RAM, the bootloader will execute to load the second-stage bootloader. The second-stage bootloader will load the kernel image into memory, decompress and initialize it, and then pass control to this kernel image. The second-stage bootloader also performs several operation on the system such as system hardware check, mounting the root device, loading the necessary kernel modules, etc. Finally, the first user-space process starts, and other high-level system initializations are performed.

In Unix-like operating systems, a device file, device node, or special file is an interface to a device driver that appears in a file system as if it were an ordinary file. There are also special files in DOS, OS/2, and Windows. These special files allow an application program to interact with a device by using its device driver via standard input/output system calls. Using standard system calls simplifies many programming tasks, and leads to consistent user-space I/O mechanisms regardless of device features and functions.

ptrace is a system call found in Unix and several Unix-like operating systems. By using ptrace one process can control another, enabling the controller to inspect and manipulate the internal state of its target. ptrace is used by debuggers and other code-analysis tools, mostly as aids to software development.

<span class="mw-page-title-main">Calculate Linux</span> Linux distribution

Calculate Linux is a Linux distribution optimized for fast deployment in an organization environment. It is based on the Gentoo Linux project and includes many preconfigured functions.

runit Init scheme and service supervisor for UNIX-like systems

runit is an init and service management scheme for Unix-like operating systems that initializes, supervises, and ends processes throughout the operating system. Runit is a reimplementation of the daemontools process supervision toolkit that runs on many Linux-based operating systems, as well as BSD, and Solaris operating systems. Runit features parallelization of the start up of system services, which can speed up the boot time of the operating system.

systemd Suite of system components for Linux

systemd is a software suite that provides an array of system components for Linux operating systems. The main aim is to unify service configuration and behavior across Linux distributions. Its primary component is a "system and service manager" — an init system used to bootstrap user space and manage user processes. It also provides replacements for various daemons and utilities, including device management, login management, network connection management, and event logging. The name systemd adheres to the Unix convention of naming daemons by appending the letter d. It also plays on the term "System D", which refers to a person's ability to adapt quickly and improvise to solve problems.

<span class="mw-page-title-main">OpenRC</span> Init system for Unix-like computer operating systems

OpenRC is a dependency-based init system for Unix-like computer operating systems. It was created by Roy Marples, a NetBSD developer who was also active in the Gentoo project. It became more broadly adopted as an init system outside of Gentoo following the decision by some Linux distributions not to adopt systemd.

A login manager is a login system for Unix and Unix-like operating systems. It comprises a login daemon, a login user interface, and a system for tracking login sessions. When a user tries to log in, the login manager passes the user's credentials to an authentication system.

References

  1. ↑ "Lennart Poettering on systemd's Tumultuous Ascendancy". The New Stack. 2018-11-08. Archived from the original on 2018-11-08. Retrieved 2024-01-30.
  2. ↑ init(8)  –  Version 7 Unix Programmer's Manual
  3. ↑ ttys(5)  –  Version 7 Unix Programmer's Manual
  4. ↑ init(8)  –  4.2BSD System Manager's Manual
  5. ↑ ttys(5)  –  4.2BSD File Formats Manual
  6. ↑ init(8)  –  4.3BSD System Manager's Manual
  7. ↑ ttys(5)  –  4.3BSD File Formats Manual
  8. ↑ Andrew Smallshaw (7 December 2009). "Unix and Linux startup scripts, Part 2". Archived from the original on 18 December 2009. Retrieved 6 June 2011.
  9. ↑ "init(8)". minnie.tuhs.org. Archived from the original on 2021-07-27. Retrieved 2015-09-12.
  10. ↑ "Initscripts". Gentoo Linux Documentation. Gentoo.org. 2014-12-13. Archived from the original on 2020-12-03. Retrieved 2020-12-08.
  11. ↑ "Run Levels". Oracle Solaris Administration: Common Tasks. Oracle. Archived from the original on 2016-04-10. Retrieved 2017-11-14.
  12. ↑ "UNIX man pages : runlevel (8)". Unixhelp.ed.ac.uk. 1997-05-27. Archived from the original on 2014-07-14. Retrieved 2014-07-12.
  13. ↑ "GitHub - davmac314/dinit: Service monitoring / "init" system". GitHub . Archived from the original on 2021-12-12. Retrieved 2021-12-12.
  14. ↑ "Epoch Init System Homepage". Archived from the original on 2014-08-02. Retrieved 2014-07-31.
  15. ↑ "Void Linux main page". Archived from the original on 2020-08-29. Retrieved 2020-08-31.
  16. ↑ "The Shepherd - GNU Project". Free Software Foundation, Inc. Archived from the original on 2016-02-12. Retrieved 2016-01-16.
  17. ↑ "s6: why another supervision suite". Archived from the original on 2021-09-13. Retrieved 2021-09-13.
  18. ↑ "s6 init system". Archived from the original on 2021-09-13.
  19. ↑ Fedora 14 Accepted Features, 2010-07-13, archived from the original on 2022-03-27, retrieved 2010-07-13
  20. ↑ "Fedora defers systemd to F15". Linux Weekly News. 2010-09-14. Archived from the original on 2010-09-19. Retrieved 2010-09-17.
  21. ↑ "Deployment". Red Hat Enterprise Linux 6: Technical Notes. Red Hat. Archived from the original on 2018-08-29. Retrieved 2013-12-31.
  22. ↑ Software Architecture: Chromium OS design documents, archived from the original on 9 April 2022, retrieved 25 January 2014
  23. ↑ See Systemd#Adoption
This page is based on this Wikipedia article
Text is available under the CC BY-SA 4.0 license; additional terms may apply.
Images, videos and audio are available under their respective licenses.