init 究竟做了什么？

Question

我正在创建一个 linux 发行版，现在我需要一个 init 程序。我可以很好地用 c 编写代码，而且我对 linux 了解很多（虽然不多，但我已经使用 arch linux 进行了 4 年的开发），所以我想我应该尝试用 C 编写我自己的基本初始化脚本。我是只是想知道，init 做了什么任务来为一个简单的 shell 设置系统？（当我问“init 有什么作用？”时，我确实知道 init 是什么以及它的用途。我只是不知道它做了什么任务。）

我不需要代码，我什至可能不需要基本命令，但我确实需要它们运行的​​顺序。

Answer 1

系统 5init只会告诉你故事的一小部分。

有一种影响 Linux 世界的近视。人们认为他们使用一种叫做“系统 5 init”的东西，这既是传统的，也是最好的起点。事实上，两者都不是。

首先，传统实际上并不是这些人所说的那样。System 5init和 System 5 可rc追溯到 AT&T UNIX System 5，它几乎与我们现在（比如）在 Linux-Mandrake 的第一个版本之后的第一个 UNIX 之后的时间一样远。

第一版 UNIX 只有init. 它没有rc。第 1 版汇编语言init（其代码已由Warren Toomey 等人恢复并提供）直接生成和重新生成 12 个getty进程，从内置表安装 3 个硬连线文件系统，并直接从主目录运行程序用户名为mel. 该getty表也​​直接在程序映像中。

在 UNIX System 5 之后又过了十年，所谓的“传统”Linux init 系统出现了。1992 年，Miquel van Smoorenburg（重新）编写了 Linux init+rc及其相关工具，人们现在将其称为“System 5 init”，尽管它实际上并不是来自 UNIX System 5 的软件（并且不仅仅是init）。

System 5 init/rc不是最好的起点，即使增加了 systemd 的知识，也不能涵盖一半的知识。仅在过去的 20 年中，就在 init 系统设计领域（针对 Linux 和 BSD）进行了大量工作。已经讨论、制定、设计、实施和实践了各种工程决策。商业 Unices 也做了很多。

可供学习和借鉴的现有系统

这是除这两个之外的一些主要 init 系统的不完整列表，以及它们的一两个（几个）突出点：

• Joachim Nilsson 的finit走的是使用更易读的配置文件的路线。
• Felix von Leitner 的minit追求文件系统即数据库配置系统、小内存占用以及启动的事物之间的启动/停止依赖关系init。
• Gerrit Pape 的runit用于我之前描述的刚刚生成的四个 shell 脚本方法。
• InitNG旨在拥有依赖项、命名目标、多个配置文件和更灵活的配置语法，为子进程加载更多设置。
• upstart进行了彻底的重新设计，将系统建模为完全不是服务和相互依赖关系，而是由它们触发的事件和作业。
• nosh的设计包括将所有服务管理（甚至包括生成getty和僵尸收割）推到一个单独的服务管理器中，并且只处理操作系统特定的“API”设备/符号链接/目录和系统事件。
• sinit是一个非常简单的初始化程序。它执行/bin/rc.init其工作是启动程序、挂载文件系统等。为此，您可以使用类似minirc 的东西。

此外，大约 10 年前，daemontools 用户和其他人就使用svscanas process #1 进行了讨论，这导致了像Paul Jarc 的 svscan 作为 process 1 study、Gerrit Pape 的想法和Laurent Bercot 的 svscan 作为 process 1 等项目。

这让我们知道进程#1 程序做了什么。

进程#1 程序做什么

进程#1“应该”做什么的概念在本质上是主观的。一个有意义的客观设计标准是流程#1至少必须做什么。内核对其提出了几个要求。并且总是有一些特定于操作系统的各种事情它必须做。当谈到流程#1传统上所做的事情时，我们并没有达到最低限度，而且从来没有真正做到过。

各种操作系统内核和其他程序对进程#1 的要求有几件事情是人们无法逃避的。

人们会告诉你，fork()处理事物并充当孤立进程的父进程是进程#1 的主要功能。具有讽刺意味的是，这是不真实的。处理孤立进程是（使用最新的 Linux 内核，如https://unix.stackexchange.com/a/177361/5132 所述）系统的一部分，可以在很大程度上将进程 #1 分解为其他进程，例如一位敬业的服务经理。所有这些都是服务管理器，用完流程 #1：

• IBM AIXsrcmstr程序，系统资源控制器
• Gerrit Paperunsvdir来自 runit
• Daniel J. Bernsteinsvscan来自 daemontools，Adam Sampsonsvscan来自freedt，Bruce Guentersvscan来自 daemontools-encore，Laurent Bercots6-svscan来自 s6
• 韦恩马歇尔perpd来自 perp
• Solaris 10 中的服务管理工具
• 在service-manager从NOSH

类似地，如https://superuser.com/a/888936/38062中所述，整个/dev/initctl想法不需要靠近进程 #1。具有讽刺意味的是，高度集中的 systemd 表明它可以从进程#1 中移出。

相反，init人们通常在他们的头顶设计中忘记的强制性事情是诸如处理SIGINT、SIGPWR、SIGWINCH等从内核发送的内容并制定发送的各种系统状态更改请求来自“知道”处理#1 的某些信号意味着某些事情的程序。（例如：如https://unix.stackexchange.com/a/196471/5132 所述，BSD 工具集“知道”SIGUSR1具有特定含义。）

还有一些一次性的初始化和终结任务是无法逃避的，或者如果不这样做就会遭受很大的痛苦，例如挂载“API”文件系统或刷新文件系统缓存。

处理“API”文件系统的基本原理与initrom 1st Edition UNIX的操作几乎没有什么不同：一个是将信息硬连线到程序中的列表，一个是列表中mount()的所有条目。您会在 BSD（原文如此！）init，通过 noshsystem-manager到 systemd 等多种多样的系统中发现这种机制。

“为一个简单的 shell 设置系统”

正如您所观察到的，init=/bin/sh没有安装“API”文件系统，在一种类型exit（https://unix.stackexchange.com/a/195978/5132）时以一种笨拙的方式崩溃并且没有缓存刷新，并且通常离开它（超级）用户手动执行使系统最小可用的操作。

要查看在过程 #1 程序中实际上别无选择，从而为您设定的设计目标设置一条良好的路线，您最好的选择是查看 Gerrit Pape 的 runit Felix von 在操作中的重叠Leitner 的 minit，以及system-manager来自 nosh 包的程序。前两者展示了两种极简主义的尝试，但仍然处理不可避免的事情。

我建议后者很有用，因为它为system-manager程序提供了大量的手动输入，它详细说明了挂载了哪些“API”文件系统、运行了哪些初始化任务以及处理了哪些信号；在按照设计让系统管理器只生成其他三个东西（服务管理器、随附的记录器和运行状态更改的程序）的系统中，并且只在进程 #1 中做不可避免的事情。