Init: Difference between revisions

From Wikipedia, the free encyclopedia
Content deleted Content added
→‎{{Anchor|S6}}Other implementations: Just directly link [Alpine Linux]].
Mark a live link as such.
 
(44 intermediate revisions by 31 users not shown)
Line 1: Line 1:
{{Short description|UNIX system component}}
{{About|the Unix process||INIT (disambiguation)}}
{{About|the Unix process||INIT (disambiguation)}}
{{Primary sources|date=December 2020}}
{{Lowercase title}}
{{Lowercase title}}
[[File:Version 7 UNIX SIMH PDP11 Etc.png|thumb|[[Version 7 Unix]]: {{mono|/etc}} listing, showing {{mono|init}} and {{mono|rc}}]]
[[File:Version 7 UNIX SIMH PDP11 Etc.png|thumb|[[Version 7 Unix]]: {{mono|/etc}} listing, showing {{mono|init}} and {{mono|rc}}]]
[[File:Version 7 UNIX SIMH PDP11 Etc Rc.png|thumb|Version 7 Unix: contents of an {{mono|/etc/rc}} [[Bourne shell]] script]]
[[File:Version 7 UNIX SIMH PDP11 Etc Rc.png|thumb|Version 7 Unix: contents of an {{mono|/etc/rc}} [[Bourne shell]] script]]


In [[Unix]]-based computer [[operating system]]s, '''init''' (short for ''initialization'') is the first [[process (computer science)|process]] started during [[booting]] of the computer system. Init is a [[daemon (computing)|daemon]] process that continues running until the system is shut down. It is the direct or indirect [[parent process|ancestor]] of all other processes and automatically adopts all [[orphan process|orphaned processes]]. Init is started by the [[Kernel (computing)|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]]-based computer [[operating system]]s, '''init''' (short for ''initialization'') is the first [[process (computer science)|process]] started during [[booting]] of the operating system. Init is a [[daemon (computing)|daemon]] process that continues running until the system is shut down. It is the direct or indirect [[parent process|ancestor]] of all other processes and automatically adopts all [[orphan process|orphaned processes]]. Init is started by the [[kernel (operating system)|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.


In Unix systems such as [[UNIX System III|System III]] and [[UNIX System V|System V]], the design of init has diverged from the functionality provided by the init in [[Research Unix]] and its [[Berkeley Software Distribution|BSD]] derivatives. Up until recently, most [[Linux distribution]]s employed a traditional init that is somewhat compatible with System V, while some distributions such as [[Slackware Linux|Slackware]] use BSD-style startup scripts, and others such as [[Gentoo Linux|Gentoo]] have their own customized versions.
In Unix systems such as [[UNIX System III|System III]] and [[UNIX System V|System V]], the design of init has diverged from the functionality provided by the init in [[Research Unix]] and its [[Berkeley Software Distribution|BSD]] derivatives. Up until the early 2010s,<ref>{{Cite web |date=2018-11-08 |title=Lennart Poettering on systemd's Tumultuous Ascendancy |website=The New Stack |url=https://thenewstack.io/unix-greatest-inspiration-behind-systemd/ |access-date=2024-01-30 |archive-url=https://web.archive.org/web/20181108025744/https://thenewstack.io/unix-greatest-inspiration-behind-systemd/ |archive-date=2018-11-08 |url-status=live}}</ref>{{failed verification|date=February 2024}} most [[Linux distribution]]s employed a traditional init that was somewhat compatible with System&nbsp;V, while some distributions such as [[Slackware Linux|Slackware]] use BSD-style startup scripts, and others such as [[Gentoo Linux|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]].
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]].


== {{Anchor|STARTUP-SCRIPTS}}Research Unix-style/BSD-style ==
== {{Anchor|STARTUP-SCRIPTS}}Research Unix-style/BSD-style ==
[[Research Unix]] init ran the initialization [[shell script]] located at <code>/etc/rc</code>,<ref>{{man|8|init|v7}}</ref> then launched [[getty (Unix)|getty]] on terminals under the control of <code>/etc/ttys</code>.<ref>{{man|5|ttys|v7}}</ref> There are no runlevels; the <code>/etc/rc</code> 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.
[[Research Unix]] init runs the initialization [[shell script]] located at <code>/etc/rc</code>,<ref>{{man|8|init|v7}}</ref> then launches [[getty (Unix)|getty]] on terminals under the control of <code>/etc/ttys</code>.<ref>{{man|5|ttys|v7}}</ref> There are no runlevels; the <code>/etc/rc</code> 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.


[[Berkeley Software Distribution|BSD]] init was, prior to 4.3BSD, the same as Research UNIX's init;<ref>{{man|8|init|4.2BSD}}</ref><ref>{{man|5|ttys|4.2BSD}}</ref> in [[4.3BSD]], it added support for running a [[windowing system]] such as [[X Window System|X]] on graphical terminals under the control of <code>/etc/ttys</code>.<ref>{{man|8|init|4.3BSD}}</ref><ref>{{man|5|ttys|4.3BSD}}</ref> To remove the requirement to edit <code>/etc/rc</code>, BSD variants have long supported a site-specific <code>/etc/rc.local</code> file that is run in a sub-shell near the end of the boot sequence.
[[Berkeley Software Distribution|BSD]] init was, prior to 4.3BSD, the same as Research UNIX's init;<ref>{{man|8|init|4.2BSD}}</ref><ref>{{man|5|ttys|4.2BSD}}</ref> in [[4.3BSD]], it added support for running a [[windowing system]] such as [[X Window System|X]] on graphical terminals under the control of <code>/etc/ttys</code>.<ref>{{man|8|init|4.3BSD}}</ref><ref>{{man|5|ttys|4.3BSD}}</ref> To remove the requirement to edit <code>/etc/rc</code>, BSD variants have long supported a site-specific <code>/etc/rc.local</code> 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 <code>/etc/rc.d</code> 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.<ref>{{cite web | url = http://aplawrence.com/Basics/unix-startup-scripts-2.html | title = Unix and Linux startup scripts, Part 2 | author = Andrew Smallshaw | date = 7 December 2009 }}</ref> The order in which scripts are executed is determined by the ''rcorder'' script based on the requirements stated in these tags.
A fully modular system was introduced with [[NetBSD]] 1.5 and ported to [[FreeBSD]] 5.0 and successors. This system executes scripts in the <code>/etc/rc.d</code> 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.<ref>{{cite web | url = http://aplawrence.com/Basics/unix-startup-scripts-2.html | title = Unix and Linux startup scripts, Part 2 | author = Andrew Smallshaw | date = 7 December 2009 | access-date = 6 June 2011 | archive-date = 18 December 2009 | archive-url = https://web.archive.org/web/20091218083059/http://aplawrence.com/Basics/unix-startup-scripts-2.html | url-status = live }}</ref> The order in which scripts are executed is determined by the ''rcorder'' utility based on the requirements stated in these tags.


== {{Anchor|SYSV}}SysV-style ==
== {{Anchor|SYSV}}SysV-style ==
[[File:Sysv-rc-conf.png|thumb|{{Mono|Sysv-rc-conf}}, a [[Text-based user interface|TUI]] utility that selects which SysV-style init scripts will be run in each runlevel]]
[[File:Sysv-rc-conf.png|thumb|{{Mono|sysv-rc-conf}}, a [[Text-based user interface|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,<ref>{{cite web|url=http://minnie.tuhs.org/cgi-bin/utree.pl?file=SysIII/usr/src/man/man8/init.8|title=init(8)|work=minnie.tuhs.org}}</ref> which survived (with modifications) into [[UNIX System V]] and is therefore called the "SysV-style init".
When compared to its predecessors, AT&T's [[UNIX System III]] introduced a new style of system startup configuration,<ref>{{cite web|url=http://minnie.tuhs.org/cgi-bin/utree.pl?file=SysIII%2Fusr%2Fsrc%2Fman%2Fman8%2Finit.8|title=init(8)|work=minnie.tuhs.org|access-date=2015-09-12|archive-date=2021-07-27|archive-url=https://web.archive.org/web/20210727193510/https://minnie.tuhs.org/cgi-bin/utree.pl?file=SysIII%2Fusr%2Fsrc%2Fman%2Fman8%2Finit.8|url-status=live}}</ref> 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 ''[[runlevel]]s''. 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 [[daemon (Unix)|daemons]], start or stop the [[X Window System]], shutdown the machine, etc.
At any moment, a running System V is in one of the predetermined number of states, called ''[[runlevel]]s''. 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 [[daemon (Unix)|daemons]], start or stop the [[X Window System]], shutdown the machine, etc.
Line 27: Line 29:
{{Details|Runlevel}}
{{Details|Runlevel}}


The [[runlevel]]s in System&nbsp;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:
The [[runlevel]]s in System&nbsp;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:
{{ordered list

|item1_value=0 | [[Shutdown (computing)|Turn off]]
: 0. Halt
: 1. [[Single user mode]] (also known as ''S'' or ''s'')
|item2_value=1 | [[Single-user mode]] (also known as ''S'' or ''s'')
: 6. [[Reboot (computing)|Reboot]]
|item3_value=6 | [[Reboot (computing)|Reboot]]
}}

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


=== Default runlevels ===
=== Default runlevels ===
{| class="wikitable floatright" style="margin-left: 1.5em;"
{| class="wikitable floatright sortable" style="margin-left: 1.5em;"
|-
|-
! Operating system
! Operating system
Line 49: Line 51:
|-
|-
| [[Gentoo Linux]]
| [[Gentoo Linux]]
| 3<ref>{{cite web |url=http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=2&chap=4 |title=Initscripts |work = Gentoo Linux Documentation |publisher=Gentoo.org |date=2011-03-02 |accessdate=2011-06-13}}</ref>
| 3<ref>{{cite web |url=https://wiki.gentoo.org/wiki/Handbook:X86/Working/Initscripts |title=Initscripts |work=Gentoo Linux Documentation |publisher=Gentoo.org |date=2014-12-13 |access-date=2020-12-08 |archive-date=2020-12-03 |archive-url=https://web.archive.org/web/20201203013811/https://wiki.gentoo.org/wiki/Handbook:X86/Working/Initscripts |url-status=live }}</ref>
|-
|-
| [[HP-UX]]
| [[HP-UX]]
Line 67: Line 69:
|-
|-
| [[Solaris (operating system)|Solaris]] / [[illumos]]
| [[Solaris (operating system)|Solaris]] / [[illumos]]
| 3<ref>{{cite web |url=https://docs.oracle.com/cd/E23824_01/html/821-1451/hbrunlevels-13026.html |title=Run Levels |publisher=[[Oracle Corporation|Oracle]] |work=Oracle Solaris Administration: Common Tasks}}</ref>
| 3<ref>{{cite web |url=https://docs.oracle.com/cd/E23824_01/html/821-1451/hbrunlevels-13026.html |title=Run Levels |publisher=[[Oracle Corporation|Oracle]] |work=Oracle Solaris Administration: Common Tasks |access-date=2017-11-14 |archive-date=2016-04-10 |archive-url=https://web.archive.org/web/20160410084238/http://docs.oracle.com/cd/E23824_01/html/821-1451/hbrunlevels-13026.html |url-status=live }}</ref>
|-
|-
| [[UNIX System V]] Releases 3.x, 4.x
| [[UNIX System V]] Releases 3.x, 4.x
Line 78: Line 80:
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 [[X display manager (program type)|display manager]] like [[GNOME Display Manager|GDM]] or [[KDE Display Manager|KDM]]. However, the [[Solaris (operating system)|Solaris]] and [[illumos]] operating systems typically reserve runlevel 5 to shut down and automatically power off the machine.
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 [[X display manager (program type)|display manager]] like [[GNOME Display Manager|GDM]] or [[KDE Display Manager|KDM]]. However, the [[Solaris (operating system)|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 <code>runlevel</code> or <code>[[who (Unix)|who]] -r</code> command.<ref>{{cite web |url=http://unixhelp.ed.ac.uk/CGI/man-cgi?runlevel+8 |title=UNIX man pages : runlevel (8) |publisher=Unixhelp.ed.ac.uk |date=1997-05-27 |accessdate=2014-07-12 |archive-url=https://web.archive.org/web/20140714112953/http://unixhelp.ed.ac.uk/CGI/man-cgi?runlevel+8 |archive-date=2014-07-14 |url-status=dead }}</ref> The [[superuser|root]] user typically changes the current runlevel by running the <code>telinit</code> or <code>init</code> commands. The <code>/etc/inittab</code> file sets the default runlevel with the <code>:initdefault:</code> entry.
On most systems, all users can check the current runlevel with either the <code>runlevel</code> or <code>[[who (Unix)|who]] -r</code> command.<ref>{{cite web |url=http://unixhelp.ed.ac.uk/CGI/man-cgi?runlevel+8 |title=UNIX man pages : runlevel (8) |publisher=Unixhelp.ed.ac.uk |date=1997-05-27 |access-date=2014-07-12 |archive-url=https://web.archive.org/web/20140714112953/http://unixhelp.ed.ac.uk/CGI/man-cgi?runlevel+8 |archive-date=2014-07-14 |url-status=dead }}</ref> The [[superuser|root]] user typically changes the current runlevel by running the <code>telinit</code> or <code>init</code> commands. The <code>/etc/inittab</code> file sets the default runlevel with the <code>:initdefault:</code> 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|date=May 2013}} 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.
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|date=May 2013}} 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.
Line 88: Line 90:
* [[GoboLinux#Boot system|BootScripts]] in [[GoboLinux]]
* [[GoboLinux#Boot system|BootScripts]] in [[GoboLinux]]
* [[Busybox|busybox-init]], suited to [[embedded operating system]]s, employed by [[OpenWrt]] before it was replaced with [[OpenWrt#procd|procd]]
* [[Busybox|busybox-init]], suited to [[embedded operating system]]s, employed by [[OpenWrt]] before it was replaced with [[OpenWrt#procd|procd]]
* Dinit, a service manager and init system.<ref>{{cite web |url=https://github.com/davmac314/dinit |title=GitHub - davmac314/dinit: Service monitoring / "init" system |website=[[GitHub]] |access-date=2021-12-12 |archive-date=2021-12-12 |archive-url=https://web.archive.org/web/20211212163253/https://github.com/davmac314/dinit |url-status=live }}</ref>
* [[Daemon (computing)|Daemons]], by a modification of the init start process by [[KahelOS]], daemons are started only when the DE (desktop environment) started<ref>{{cite web|url=http://archives.free.net.ph/message/20091225.165529.72fd0135.en.html | title=Why is KahelOS Linux faster than before?|author=Meric Mara|website=archives.free.net.ph|access-date=2018-06-13}}</ref>{{citation needed|date=July 2014}}{{Specify|reason=What are those modifications, and do they involve running some program other than the traditional Linux SV-compatible init, or systemd, as process 1?|date=January 2019}}
* [[Epoch (init system)|Epoch]], a single-threaded Linux init system focused on simplicity and service management<ref>{{cite web |url=http://universe2.us/epoch.html |title=Epoch Init System Homepage |access-date=2014-07-31 |archive-date=2014-08-02 |archive-url=https://web.archive.org/web/20140802142947/http://universe2.us/epoch.html |url-status=live }}</ref>
* eINIT, a full replacement of init designed to start processes [[Asynchrony (computer programming)|asynchronously]], but with the potential of doing it without [[shell scripts]]<ref>{{cite web|url=https://github.com/eINIT/xml-sh/tree/master/data/modules-xml | title=eINIT git repository XML module directory}}</ref>
* [[Epoch (init system)|Epoch]], a single-threaded Linux init system focused on simplicity and service management<ref>{{cite web|url=http://universe2.us/epoch.html | title=Epoch Init System Homepage}}</ref>
* [[Initng]], a full replacement of init designed to start processes asynchronously
* [[Initng]], a full replacement of init designed to start processes asynchronously
* [[launchd]], a replacement for init in [[Darwin (operating system)|Darwin]]/[[macOS]]/[[iOS]]/[[tvOS]] starting with [[Mac&nbsp;OS&nbsp;X v10.4]] (it launches SystemStarter to run old-style <nowiki>'rc.local'</nowiki> and SystemStarter processes)
* [[launchd]], a replacement for init in [[Darwin (operating system)|Darwin]]/[[macOS]]/[[iOS]]/[[tvOS]] starting with [[Mac&nbsp;OS&nbsp;X v10.4]] (it launches SystemStarter to run old-style <nowiki>'rc.local'</nowiki> and SystemStarter processes)
* [https://web.archive.org/web/20071211041543/http://www.pardus.org.tr/eng/projeler/comar/SpeedingUpLinuxWithPardus.html Mudur], an init replacement written in [[Python (programming language)|Python]] and designed to start process asynchronously in use by the [[Pardus (operating system)|Pardus]] Linux distribution<ref>{{cite web |url=http://www.pardus.org.tr/eng/projects/comar/SpeedingUpLinuxWithPardus.html |title=Speeding Up Linux: One Step Further With Pardus Pardus |author=Gürer Özen, Görkem Çetin |publisher=Pardus.org.tr |accessdate=2011-06-13 |url-status=dead |archiveurl=https://web.archive.org/web/20110705091640/http://www.pardus.org.tr/eng/projects/comar/SpeedingUpLinuxWithPardus.html |archivedate=2011-07-05 }}</ref>
* [https://lede-project.org/docs/guide-developer/procd procd] is used in LEDE/OpenWRT
* [https://web.archive.org/web/20070824084840/http://www-128.ibm.com/developerworks/linux/library/l-boot.html some unnamed proofs-of concept] based on [[Make (software)|Make]] (since makefiles can easily express dependencies and be launched in parallel)
* nosh, a suite of system-level utilities for initializing and running a BSD or Linux system, for managing daemons, terminals and logging<ref>{{cite web|url=http://jdebp.eu/Softwares/nosh/ |title=The nosh package | author = Jonathan de Boyne Pollard |publisher=Jonathan de Boyne Pollard |date= |accessdate=2018-05-21}}</ref>
* [[OpenRC]], a process spawner that utilizes system-provided init, while providing process isolation, parallelized startup, and service dependency; used by [[Alpine Linux]], [[Gentoo Linux|Gentoo]] and its derivatives, and available as an option in [[Devuan]] and [[Artix Linux]]
* [[OpenRC]], a process spawner that utilizes system-provided init, while providing process isolation, parallelized startup, and service dependency; used by [[Alpine Linux]], [[Gentoo Linux|Gentoo]] and its derivatives, and available as an option in [[Devuan]] and [[Artix Linux]]
* [[runit]], a cross-platform full replacement for init with parallel starting of services, used by default in [[Void Linux]]<ref>[http://voidlinux.org Void Linux main page]</ref>
* [[runit]], a cross-platform full replacement for init with parallel starting of services, used by default in [[Void Linux]]<ref>{{Cite web |url=http://voidlinux.org/ |title=Void Linux main page |access-date=2020-08-31 |archive-date=2020-08-29 |archive-url=https://web.archive.org/web/20200829154800/https://voidlinux.org/ |url-status=live }}</ref>
* [https://skarnet.org/software/s6/ s6], another cross-platform full replacement for init, similar to runit
* Sun [[Service Management Facility]] (SMF), a complete replacement/redesign of init from the ground up in [[illumos]]/[[Solaris (operating system)|Solaris]] starting with Solaris 10, but launched as the only service by the original System&nbsp;V-style init
* Sun [[Service Management Facility]] (SMF), a complete replacement/redesign of init from the ground up in [[illumos]]/[[Solaris (operating system)|Solaris]] starting with Solaris 10, but launched as the only service by the original System&nbsp;V-style init
* [[GNU Guix System#GNU Shepherd init system|Shepherd]], the [[GNU]] service and daemon manager which provides asynchronous, dependency-based initialisation; written in [[Guile (programming language)|Guile Scheme]] and meant to be interactively hackable during normal system operation<ref>{{cite web|url=https://www.gnu.org/software/shepherd/ |title=The Shepherd - GNU Project | author= | publisher=Free Software Foundation, Inc. |date= |accessdate=2016-01-16}}</ref>
* [[GNU Guix System#GNU Shepherd init system|Shepherd]], the [[GNU]] service and daemon manager which provides asynchronous, dependency-based initialisation; written in [[Guile (programming language)|Guile Scheme]] and meant to be interactively hackable during normal system operation<ref>{{cite web |url=https://www.gnu.org/software/shepherd/ |title=The Shepherd - GNU Project |publisher=Free Software Foundation, Inc. |access-date=2016-01-16 |archive-date=2016-02-12 |archive-url=https://web.archive.org/web/20160212224150/https://www.gnu.org/software/shepherd/ |url-status=live }}</ref>
* [[S6 (software)|s6]], a software suite that includes an init system. <ref>{{cite web |url=https://www.skarnet.org/software/s6/why.html |title=s6: why another supervision suite |access-date=2021-09-13 |archive-date=2021-09-13 |archive-url=https://web.archive.org/web/20210913201711/https://skarnet.org/software/s6/why.html |url-status=live }}</ref><ref>{{cite web |url=https://www.linuxquestions.org/questions/slackware-14/s6-init-system-4175658553/ |url-status=dead |archive-url=https://web.archive.org/web/20210913201707/https://www.linuxquestions.org/questions/slackware-14/s6-init-system-4175658553/ |archive-date=2021-09-13 |title=s6 init system}}</ref>
* [[systemd]], a software suite, full replacement for init in Linux that includes an init daemon, with concurrent starting of services, service manager, and other features.
* [[systemd]], a software suite, full replacement for init in Linux that includes an init daemon, with concurrent starting of services, service manager, and other features.
* [[SystemStarter]], a process spawner started by the BSD-style init in [[Mac&nbsp;OS&nbsp;X]] prior to Mac&nbsp;OS&nbsp;X v10.4
* [[SystemStarter]], a process spawner started by the BSD-style init in [[Mac&nbsp;OS&nbsp;X]] prior to Mac&nbsp;OS&nbsp;X v10.4
* [[Upstart (software)|Upstart]], a full replacement of init designed to start processes asynchronously. Initiated by [[Ubuntu (operating system)|Ubuntu]] and used by them until 2014. It was also used in Fedora 9,<ref>{{citation |url=https://fedoraproject.org/wiki/Releases/14/FeatureList |title=Fedora 14 Accepted Features |date=2010-07-13 |accessdate=2010-07-13}}</ref><ref>{{cite web |url=https://lwn.net/Articles/405100/ |title=Fedora defers systemd to F15 |date=2010-09-14 |accessdate=2010-09-17 |publisher=Linux Weekly News}}</ref> Red Hat Enterprise Linux 6<ref>{{cite web |url=https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/6.0_technical_notes/deployment|publisher=[[Red Hat]] |title=Deployment |work=Red Hat Enterprise Linux 6: Technical Notes |accessdate=2013-12-31}}</ref> and [[Google]]'s [[Chrome OS]].<ref name="chrome-os">{{citation |url=https://sites.google.com/a/chromium.org/dev/chromium-os/chromiumos-design-docs/software-architecture |title=Software Architecture: Chromium OS design documents |publisher=Google |accessdate=25 January 2014}}</ref>
* [[Upstart (software)|Upstart]], a full replacement of init designed to start processes asynchronously. Initiated by [[Ubuntu (operating system)|Ubuntu]] and used by them until 2014. It was also used in Fedora 9,<ref>{{citation |url=https://fedoraproject.org/wiki/Releases/14/FeatureList |title=Fedora 14 Accepted Features |date=2010-07-13 |access-date=2010-07-13 |archive-date=2022-03-27 |archive-url=https://web.archive.org/web/20220327191742/https://fedoraproject.org/wiki/Releases/14/FeatureList |url-status=live }}</ref><ref>{{cite web |url=https://lwn.net/Articles/405100/ |title=Fedora defers systemd to F15 |date=2010-09-14 |access-date=2010-09-17 |publisher=Linux Weekly News |archive-date=2010-09-19 |archive-url=https://web.archive.org/web/20100919142259/http://lwn.net/Articles/405100/ |url-status=live }}</ref> Red Hat Enterprise Linux 6<ref>{{cite web |url=https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/6.0_technical_notes/deployment |publisher=[[Red Hat]] |title=Deployment |work=Red Hat Enterprise Linux 6: Technical Notes |access-date=2013-12-31 |archive-date=2018-08-29 |archive-url=https://web.archive.org/web/20180829175441/https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/6.0_technical_notes/deployment |url-status=live }}</ref> and [[Google]]'s [[ChromeOS]].<ref name="chrome-os">{{citation |url=https://sites.google.com/a/chromium.org/dev/chromium-os/chromiumos-design-docs/software-architecture |title=Software Architecture: Chromium OS design documents |access-date=25 January 2014 |archive-date=9 April 2022 |archive-url=https://web.archive.org/web/20220409203000/https://sites.google.com/a/chromium.org/dev/chromium-os/chromiumos-design-docs/software-architecture |url-status=live }}</ref>


{{As of|2019|2}}, systemd has been [[Systemd#Adoption and reception|adopted]] by most major Linux distributions.<ref>See [[Systemd#Adoption]]</ref>
{{As of|2019|2}}, systemd has been [[Systemd#Adoption|adopted]] by most major Linux distributions.<ref>See [[Systemd#Adoption]]</ref>


== See also ==
== See also ==
Line 119: Line 116:
* [https://arxiv.org/abs/0706.2748 A paper summarizing Unix init schemes] (2007)
* [https://arxiv.org/abs/0706.2748 A paper summarizing Unix init schemes] (2007)
* {{webarchive |url=https://web.archive.org/web/20051231110711/http://www.sun.com/bigadmin/content/selfheal/smf-quickstart.html |date=December 31, 2005 |title=Solaris Service Management Facility - Quickstart Guide }}
* {{webarchive |url=https://web.archive.org/web/20051231110711/http://www.sun.com/bigadmin/content/selfheal/smf-quickstart.html |date=December 31, 2005 |title=Solaris Service Management Facility - Quickstart Guide }}
* [http://blog.darknedgy.net/technology/2015/09/05/0/ A history of modern init systems (1992&ndash;2015)]
* [http://blog.darknedgy.net/technology/2015/09/05/0/ A history of modern init systems (1992&ndash;2015)] {{Webarchive|url=https://web.archive.org/web/20151011235646/http://blog.darknedgy.net/technology/2015/09/05/0/ |date=2015-10-11 }}


{{Service management in Unix}}
{{Service management in Unix}}

Latest revision as of 09:13, 8 March 2024

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 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.

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 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[edit]

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[edit]

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[edit]

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[edit]

Operating system Default 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.x 2
UnixWare 7.x 3

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[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 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:

  • BootScripts in GoboLinux
  • busybox-init, suited to embedded operating systems, employed by OpenWrt before it was replaced with procd
  • Dinit, a service manager and init system.[13]
  • Epoch, a single-threaded Linux init system focused on simplicity and service management[14]
  • Initng, a full replacement of init designed to start processes asynchronously
  • launchd, a replacement for init in Darwin/macOS/iOS/tvOS starting with Mac OS X v10.4 (it launches SystemStarter to run old-style 'rc.local' and SystemStarter processes)
  • OpenRC, a process spawner that utilizes system-provided init, while providing process isolation, parallelized startup, and service dependency; used by Alpine Linux, Gentoo and its derivatives, and available as an option in Devuan and Artix Linux
  • runit, a cross-platform full replacement for init with parallel starting of services, used by default in Void Linux[15]
  • Sun Service Management Facility (SMF), a complete replacement/redesign of init from the ground up in illumos/Solaris starting with Solaris 10, but launched as the only service by the original System V-style init
  • Shepherd, the GNU service and daemon manager which provides asynchronous, dependency-based initialisation; written in Guile Scheme and meant to be interactively hackable during normal system operation[16]
  • s6, a software suite that includes an init system. [17][18]
  • systemd, a software suite, full replacement for init in Linux that includes an init daemon, with concurrent starting of services, service manager, and other features.
  • 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 and used by them until 2014. It was also used in Fedora 9,[19][20] Red Hat Enterprise Linux 6[21] and Google's ChromeOS.[22]

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

See also[edit]

References[edit]

  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

External links[edit]