进一步阅读

Question 1

init是在进程 #1 中运行的程序的常规名称。多年来，它采取了多种形式，并且init项目执行的任务也有很大差异。令人困惑的是，它也是管理员用来与进程 #1 通信的命令的名称。它们最好被视为两个独立的事物，并且在 AT&T Unix 中肯定以这种方式记录，即使它们在某些软件中全部混合在一个程序中，该程序根据它发现的进程 ID 具有不同的行为。更令人困惑的是，在系统的生命周期中，进程 #1 可以运行多个不同的程序，其中至少有两个程序（在具有 initramfs 的 Linux 系统的情况下）被命名init（/init在 initramfs 和/sbin/init最终的根文件系统中，通常由前者链接）。

A服务经理顾名思义，是一个管理服务的程序。它不必作为进程 #1 运行，事实上，多年来在广泛的操作系统软件中，一般没有被流程#1。服务经理包括 Gerrit Pape 的runsv通过洛朗·贝尔科特s6-supervise到富有想象力的名字service-manager在我的零食里。它们还包括 AT&T Unix System 5 Release 4 的服务访问工具、IBM AIX 3.1 的系统资源控制器以及 Solaris 的服务管理工具。它们从统一、一致、已知的上下文中生成服务程序，并提供控制这些服务（启动、终止、重新启动和取消）的机制以及系统其余部分查询其状态的机制。

A系统管理员是管理系统、处理系统状态变化的程序。它一般是作为进程#1 运行。这部分是因为操作系统的内核对其进行了特殊处理，向其发送有关系统状态更改请求的信息，例如电源故障事件或内核虚拟终端键盘设备上的特殊键和弦（例如在 Linux ⇮+上↑生成SIGWINCH或⎈+ ⎇+⌦生成SIGINT进程#1)。它还负责在引导时设置初始系统状态，有时还负责在关闭时最终确定系统状态。

系统状态的详细信息因软件而异。 van Smoorenburginit按照（现已过时）运行级别进行操作。 BSDinit的状态机完全是内部的，具有以下状态：跑步/etc/rc,多用户，和单用户。

实例探究：

systemd是一个进程#1 程序。它在一个程序中执行服务管理和系统管理，并作为该进程运行。但是，它不处理最终确定系统状态，而是将进程 #1 链接到名为的不同程序systemd-shutdown为了那个原因。系统状态更改通常采取服务管理器启动/停止的形式目标这反过来又导致启动/停止服务。emergency.service例如，一些服务systemd-halt.service在激活时会自行运行systemctl，将命令发送回进程#1，以进行进一步的系统状态更改。在本设计中，关闭是一个两种状态的序列。
充满想象力的名字system-manager在我的 nosh Tooset 中，有一个进程 #1 程序，它只扮演系统管理员的角色。它在引导时进行初始化，并在关闭时进行终结。它通过生成（系统范围的）服务管理器来管理系统作为另一个进程以及各种调用system-control响应事件的程序。（例如， KVT 键盘上的+ +SIGINT和弦导致它生成一个要运行的子进程。）向服务管理器发出命令以启动和停止服务和目标。类似地，多个服务/目标调用将命令发送回⎈⎇⌦system-control start secure-attention-keysystem-controlsystem-control系统管理器，以便在它们激活时请求进一步的系统状态更改。服务进程是进程 #1 的孙子进程。
runit是一个进程 #1 程序，也只进行系统管理。它像其他进程一样产生服务管理器。这是通过调用 shell 脚本来完成的，runit 人们称之为“第 2 阶段”，该脚本依次链式加载runsvdir这又会产生几个runsv程序作为进程 #1 的孙进程。服务进程是进程#1 的曾孙。系统管理采用“仅运行三个 shell 脚本”的方法，由信号和标志文件的组合触发。
系统 5init是一个进程 #1 程序，仅进行系统管理。它具有前面提到的系统状态运行级别，理论上也可以是服务管理器。事实上，它的服务管理功能非常差，几年后甚至不再用于 TUI 登录服务管理。它以前面提到的 SAF 和 SRC 的形式生成了（功能更强大的）服务管理器作为子进程。
到 1990 年，使用的运行级别数量减少到 1，在system-manager几十年后的实际操作中产生与 nosh 几乎相同的设计，进程 #1 很大程度上只是生成一个服务管理器子进程和更多子进程来运行命令响应内核事件和管理员命令。服务进程是进程 #1 的曾孙进程、各种服务管理器进程的孙子进程和子进程。（TUI 登录服务进程是由进程生成的ttymon，它本身是从sac进程生成的，例如，由进程 #1 生成的。）
van Smoorenburg就像前面提到的 Unix 服务管理器出现前几年的系统 3和系统 5init一样。它是一个进程 #1 程序，执行系统管理器角色，并且还管理一些服务（尽管以相同的功能较差的方式，不允许对启动/停止单个服务进行细粒度控制，如系统 5 ）。服务管理，如果确实完成的话（而不是仅仅分叉服务程序并在很大程度上忘记它们），是由子进程中的其他程序完成的。initinitinit
systemd与两者和 nosh 工具集相反，system-manager它将一些系统管理操作留给在子进程中运行的程序。虽然和都systemd在system-manager进程 #1 中执行系统断电/重新启动/停止的最终操作（对内核进行适当的系统调用）（尽管在 systemd 情况下是在另一个程序中），但在 van Smoorenburg 系统中，这些操作是在子进程中执行的通过调用rc。例如：停止系统的最终系统调用是通过halt作为子进程rc（本身是进程 #1 的子进程）运行的 shell 脚本执行的。依次运行halt程序（作为进程 #1 的曾孙）实际上进行系统调用。

进一步阅读

乔纳森·德博因·波拉德 (2018)。 Unix 服务访问工具。常见答案。
乔纳森·德博因·波拉德 (2015)。 /etc/inittab已成为过去。。常见答案。
乔纳森·德博因·波拉德 (2018)。 运行级别已成为过去。。常见答案。
乔纳森·德博因·波拉德 (2018)。 getty产生于init已成为过去。。常见答案。
Linux - 带 init 的 IPC
init到底做了什么？
这些用于关闭 Linux 服务器的命令有什么区别？
https://retrocomputing.stackexchange.com/a/8290/1932

Answer

init是在进程 #1 中运行的程序的常规名称。多年来，它采取了多种形式，并且init项目执行的任务也有很大差异。令人困惑的是，它也是管理员用来与进程 #1 通信的命令的名称。它们最好被视为两个独立的事物，并且在 AT&T Unix 中肯定以这种方式记录，即使它们在某些软件中全部混合在一个程序中，该程序根据它发现的进程 ID 具有不同的行为。更令人困惑的是，在系统的生命周期中，进程 #1 可以运行多个不同的程序，其中至少有两个程序（在具有 initramfs 的 Linux 系统的情况下）被命名init（/init在 initramfs 和/sbin/init最终的根文件系统中，通常由前者链接）。

A服务经理顾名思义，是一个管理服务的程序。它不必作为进程 #1 运行，事实上，多年来在广泛的操作系统软件中，一般没有被流程#1。服务经理包括 Gerrit Pape 的runsv通过洛朗·贝尔科特s6-supervise到富有想象力的名字service-manager在我的零食里。它们还包括 AT&T Unix System 5 Release 4 的服务访问工具、IBM AIX 3.1 的系统资源控制器以及 Solaris 的服务管理工具。它们从统一、一致、已知的上下文中生成服务程序，并提供控制这些服务（启动、终止、重新启动和取消）的机制以及系统其余部分查询其状态的机制。

A系统管理员是管理系统、处理系统状态变化的程序。它一般是作为进程#1 运行。这部分是因为操作系统的内核对其进行了特殊处理，向其发送有关系统状态更改请求的信息，例如电源故障事件或内核虚拟终端键盘设备上的特殊键和弦（例如在 Linux ⇮+上↑生成SIGWINCH或⎈+ ⎇+⌦生成SIGINT进程#1)。它还负责在引导时设置初始系统状态，有时还负责在关闭时最终确定系统状态。

系统状态的详细信息因软件而异。 van Smoorenburginit按照（现已过时）运行级别进行操作。 BSDinit的状态机完全是内部的，具有以下状态：跑步/etc/rc,多用户，和单用户。

实例探究：

systemd是一个进程#1 程序。它在一个程序中执行服务管理和系统管理，并作为该进程运行。但是，它不处理最终确定系统状态，而是将进程 #1 链接到名为的不同程序systemd-shutdown为了那个原因。系统状态更改通常采取服务管理器启动/停止的形式目标这反过来又导致启动/停止服务。emergency.service例如，一些服务systemd-halt.service在激活时会自行运行systemctl，将命令发送回进程#1，以进行进一步的系统状态更改。在本设计中，关闭是一个两种状态的序列。
充满想象力的名字system-manager在我的 nosh Tooset 中，有一个进程 #1 程序，它只扮演系统管理员的角色。它在引导时进行初始化，并在关闭时进行终结。它通过生成（系统范围的）服务管理器来管理系统作为另一个进程以及各种调用system-control响应事件的程序。（例如， KVT 键盘上的+ +SIGINT和弦导致它生成一个要运行的子进程。）向服务管理器发出命令以启动和停止服务和目标。类似地，多个服务/目标调用将命令发送回⎈⎇⌦system-control start secure-attention-keysystem-controlsystem-control系统管理器，以便在它们激活时请求进一步的系统状态更改。服务进程是进程 #1 的孙子进程。
runit是一个进程 #1 程序，也只进行系统管理。它像其他进程一样产生服务管理器。这是通过调用 shell 脚本来完成的，runit 人们称之为“第 2 阶段”，该脚本依次链式加载runsvdir这又会产生几个runsv程序作为进程 #1 的孙进程。服务进程是进程#1 的曾孙。系统管理采用“仅运行三个 shell 脚本”的方法，由信号和标志文件的组合触发。
系统 5init是一个进程 #1 程序，仅进行系统管理。它具有前面提到的系统状态运行级别，理论上也可以是服务管理器。事实上，它的服务管理功能非常差，几年后甚至不再用于 TUI 登录服务管理。它以前面提到的 SAF 和 SRC 的形式生成了（功能更强大的）服务管理器作为子进程。
到 1990 年，使用的运行级别数量减少到 1，在system-manager几十年后的实际操作中产生与 nosh 几乎相同的设计，进程 #1 很大程度上只是生成一个服务管理器子进程和更多子进程来运行命令响应内核事件和管理员命令。服务进程是进程 #1 的曾孙进程、各种服务管理器进程的孙子进程和子进程。（TUI 登录服务进程是由进程生成的ttymon，它本身是从sac进程生成的，例如，由进程 #1 生成的。）
van Smoorenburg就像前面提到的 Unix 服务管理器出现前几年的系统 3和系统 5init一样。它是一个进程 #1 程序，执行系统管理器角色，并且还管理一些服务（尽管以相同的功能较差的方式，不允许对启动/停止单个服务进行细粒度控制，如系统 5 ）。服务管理，如果确实完成的话（而不是仅仅分叉服务程序并在很大程度上忘记它们），是由子进程中的其他程序完成的。initinitinit
systemd与两者和 nosh 工具集相反，system-manager它将一些系统管理操作留给在子进程中运行的程序。虽然和都systemd在system-manager进程 #1 中执行系统断电/重新启动/停止的最终操作（对内核进行适当的系统调用）（尽管在 systemd 情况下是在另一个程序中），但在 van Smoorenburg 系统中，这些操作是在子进程中执行的通过调用rc。例如：停止系统的最终系统调用是通过halt作为子进程rc（本身是进程 #1 的子进程）运行的 shell 脚本执行的。依次运行halt程序（作为进程 #1 的曾孙）实际上进行系统调用。

进一步阅读

乔纳森·德博因·波拉德 (2018)。 Unix 服务访问工具。常见答案。
乔纳森·德博因·波拉德 (2015)。 /etc/inittab已成为过去。。常见答案。
乔纳森·德博因·波拉德 (2018)。 运行级别已成为过去。。常见答案。
乔纳森·德博因·波拉德 (2018)。 getty产生于init已成为过去。。常见答案。
Linux - 带 init 的 IPC
init到底做了什么？
这些用于关闭 Linux 服务器的命令有什么区别？
https://retrocomputing.stackexchange.com/a/8290/1932

Question 2

这是一个非常好的问题，但不是一个可以很快回答的问题。我的回答是对杰德BP的。

当我们谈论“init 系统”时，我们实际上是在谈论 4 个不同的事物，请参见下文。这是一个令人困惑的领域，因为很少有人真正花时间来区分所涉及的概念 - 甚至那些有时对术语持不同意见的人！ :-)

例如，乔纳森称之为服务经理，我称之为过程监督制度，因为它管理的是流程，而不是服务。更准确地说，它提供了一个抽象（“服务”，尽管它只涵盖了长跑服务，即通过守护进程实现的服务），同时隐藏该抽象（进程）的实现，以便用户可以解决服务代替进程。

乔纳森称之为系统管理员，我称之为服务经理，因为它实际上是一个启动和停止服务的工具，所以它可以说是管理它们的——但它是处理机器全局状态的工具，所以“系统管理器”术语也是有意义的。尽管我更愿意机器状态管理器。无论如何，我们应该就这些条款达成共识，这将极大地有助于减少混乱。

那么，什么是init系统呢？其实就是4件事：

机器启动时运行的第一个程序。传统上，它被命名为/sbin/init，这就是我在处理该程序时使用的术语。
运行时间较长的程序进程号1在机器的大部分使用寿命期间。它可能与相同，也可能不同/sbin/init，因为/sbin/init可能会执行到其他程序中。对于 sysvinit 或 systemd，进程号1是/sbin/init。对于基于 s6 的系统来说，情况并非如此。
A过程监督制度。这基本上是一个在守护进程死亡时重新启动的系统，以及解决守护进程当前化身的工具，无论它有什么 pid。对于一个 init 系统来说，至少有一个进程必须具备这一点，因为如果没有，那么系统上的所有进程（保存进程号1）可能会死掉，机器将变得无法使用并需要从控制台重新启动。
A机器状态管理器（以避免含糊的术语）。该软件可以将您的计算机状态从“一切都已关闭”变为“我想要的所有服务都已启动”，并且还可以在计算机运行时更改正在运行的服务集，并触发关闭。

这些是 init 系统的 4 个重要部分。那么，现有的 init 系统是如何工作的呢？

sysvinit 提供/sbin/init，进程号1，一个非常初级的监督体系（通过中的行实现/etc/inittab），并且没有机器状态管理器。使用 sysvinit 的发行版通常使用 sysv-rc（传统的 shell 脚本集）或 OpenRC 作为机器状态管理器。
OpenRC 是一个机器状态管理器。它的最新版本还提供了一个基本的监督体系。但它不提供/sbin/init或进程号1：OpenRC 本身不是一个初始化系统。
systemd 在单个进程中提供所有 4 个元素。所以，是的，systemd 既是“init”（这可能意味着/sbin/init或进程号1或两者）和“服务经理”，“服务经理”是否意味着监督体系或者机器状态管理器。
所有类似 daemontools 的方法本质上都是监督系统。运行还提供了一个/sbin/init和进程号1。s6提供了一个进程号1，但是没有/sbin/init，但是s6-linux-init包提供了一个/sbin/init.这些方法并没有提供机器状态管理器，但是 s6 为此类管理器提供了钩子，并且已经编写了两个：s6-rc和阿诺帕。
开胃菜在单独的进程中提供所有 4 个元素。乔纳森将能够比我更好地谈论它。 :-)
当您查看任何其他 init 系统（busybox init、BSD init、launchd、Epoch 等其他方法）时，最好想一下：这个 init 提供了哪些元素？它缺少什么？

我有一个 15 分钟的视频解释了我在这篇文章中只能简要总结的内容，还有一组更大的幻灯片深入探讨了 init 系统的工作原理。所有这些都可以在FOSDEM 2017 档案。请随意探索。如果您对这些事情感兴趣，我们将在监督邮件列表。

享受，

Answer

这是一个非常好的问题，但不是一个可以很快回答的问题。我的回答是对杰德BP的。

当我们谈论“init 系统”时，我们实际上是在谈论 4 个不同的事物，请参见下文。这是一个令人困惑的领域，因为很少有人真正花时间来区分所涉及的概念 - 甚至那些有时对术语持不同意见的人！ :-)

例如，乔纳森称之为服务经理，我称之为过程监督制度，因为它管理的是流程，而不是服务。更准确地说，它提供了一个抽象（“服务”，尽管它只涵盖了长跑服务，即通过守护进程实现的服务），同时隐藏该抽象（进程）的实现，以便用户可以解决服务代替进程。

乔纳森称之为系统管理员，我称之为服务经理，因为它实际上是一个启动和停止服务的工具，所以它可以说是管理它们的——但它是处理机器全局状态的工具，所以“系统管理器”术语也是有意义的。尽管我更愿意机器状态管理器。无论如何，我们应该就这些条款达成共识，这将极大地有助于减少混乱。

那么，什么是init系统呢？其实就是4件事：

机器启动时运行的第一个程序。传统上，它被命名为/sbin/init，这就是我在处理该程序时使用的术语。
运行时间较长的程序进程号1在机器的大部分使用寿命期间。它可能与相同，也可能不同/sbin/init，因为/sbin/init可能会执行到其他程序中。对于 sysvinit 或 systemd，进程号1是/sbin/init。对于基于 s6 的系统来说，情况并非如此。
A过程监督制度。这基本上是一个在守护进程死亡时重新启动的系统，以及解决守护进程当前化身的工具，无论它有什么 pid。对于一个 init 系统来说，至少有一个进程必须具备这一点，因为如果没有，那么系统上的所有进程（保存进程号1）可能会死掉，机器将变得无法使用并需要从控制台重新启动。
A机器状态管理器（以避免含糊的术语）。该软件可以将您的计算机状态从“一切都已关闭”变为“我想要的所有服务都已启动”，并且还可以在计算机运行时更改正在运行的服务集，并触发关闭。

这些是 init 系统的 4 个重要部分。那么，现有的 init 系统是如何工作的呢？

sysvinit 提供/sbin/init，进程号1，一个非常初级的监督体系（通过中的行实现/etc/inittab），并且没有机器状态管理器。使用 sysvinit 的发行版通常使用 sysv-rc（传统的 shell 脚本集）或 OpenRC 作为机器状态管理器。
OpenRC 是一个机器状态管理器。它的最新版本还提供了一个基本的监督体系。但它不提供/sbin/init或进程号1：OpenRC 本身不是一个初始化系统。
systemd 在单个进程中提供所有 4 个元素。所以，是的，systemd 既是“init”（这可能意味着/sbin/init或进程号1或两者）和“服务经理”，“服务经理”是否意味着监督体系或者机器状态管理器。
所有类似 daemontools 的方法本质上都是监督系统。运行还提供了一个/sbin/init和进程号1。s6提供了一个进程号1，但是没有/sbin/init，但是s6-linux-init包提供了一个/sbin/init.这些方法并没有提供机器状态管理器，但是 s6 为此类管理器提供了钩子，并且已经编写了两个：s6-rc和阿诺帕。
开胃菜在单独的进程中提供所有 4 个元素。乔纳森将能够比我更好地谈论它。 :-)
当您查看任何其他 init 系统（busybox init、BSD init、launchd、Epoch 等其他方法）时，最好想一下：这个 init 提供了哪些元素？它缺少什么？

我有一个 15 分钟的视频解释了我在这篇文章中只能简要总结的内容，还有一组更大的幻灯片深入探讨了 init 系统的工作原理。所有这些都可以在FOSDEM 2017 档案。请随意探索。如果您对这些事情感兴趣，我们将在监督邮件列表。

享受，

Question 3

init（通常）是系统启动的第一个进程。它有一些特殊职责，包括（但不限于）：

启动完成启动过程所需的任何其他用户空间进程。
处理系统的最终关闭（init一旦用户空间中的所有内容都关闭，最终会告诉内核关闭电源或重新启动）。
采用孤立进程（不再有正在运行的父进程的进程）并在它们之后进行清理。

另一方面，服务管理器仅负责确保给定的一组服务正在运行，并且可以选择确保它们保持运行。实现此目的的确切方法可能有所不同，从仅跟踪服务之间依赖关系的基本脚本到自动管理依赖关系的复杂系统。

最初的 SVR4实现（它是大多数 Linux 发行版上的经典软件包、Busybox小程序以及 BSD 和 Solaris程序init的基础）实际上包括基本的服务管理。它允许您定义在启动时自动启动的程序，并在退出时重新启动。因此，实际上很难在类似 UNIX 的系统上找到一个不是基本服务管理器的实现，并且这种服务管理的基线级别在很大程度上意味着是流程工作的一部分。systemv-initinitinitinitinit

另一方面，您可以轻松拥有一个不是实现的服务管理器init。经典的 BSD脚本是一个非常简单的服务管理器的示例（它们处理启动和停止服务，并提供基本的依赖关系管理），它们构成了Linuxrc.d概念的基础。/etc/init.d一个更复杂的例子是 monit，它在基本功能的基础上添加了状态跟踪、自动重启功能、警报和一些系统监控支持。

Answer

init（通常）是系统启动的第一个进程。它有一些特殊职责，包括（但不限于）：

启动完成启动过程所需的任何其他用户空间进程。
处理系统的最终关闭（init一旦用户空间中的所有内容都关闭，最终会告诉内核关闭电源或重新启动）。
采用孤立进程（不再有正在运行的父进程的进程）并在它们之后进行清理。

另一方面，服务管理器仅负责确保给定的一组服务正在运行，并且可以选择确保它们保持运行。实现此目的的确切方法可能有所不同，从仅跟踪服务之间依赖关系的基本脚本到自动管理依赖关系的复杂系统。

最初的 SVR4实现（它是大多数 Linux 发行版上的经典软件包、Busybox小程序以及 BSD 和 Solaris程序init的基础）实际上包括基本的服务管理。它允许您定义在启动时自动启动的程序，并在退出时重新启动。因此，实际上很难在类似 UNIX 的系统上找到一个不是基本服务管理器的实现，并且这种服务管理的基线级别在很大程度上意味着是流程工作的一部分。systemv-initinitinitinitinit

另一方面，您可以轻松拥有一个不是实现的服务管理器init。经典的 BSD脚本是一个非常简单的服务管理器的示例（它们处理启动和停止服务，并提供基本的依赖关系管理），它们构成了Linuxrc.d概念的基础。/etc/init.d一个更复杂的例子是 monit，它在基本功能的基础上添加了状态跟踪、自动重启功能、警报和一些系统监控支持。

进一步阅读

答案1

进一步阅读

答案2

答案3

相关内容