Linux发行版的新服务管理器

服务管理人员是Linux发行版的基本部分 - 以及Unix系统的基本部分。不幸的是，对于这种关键的基础设施，缺乏报价。没有服务经理执行所有职责用户可以从中期望的所有职责，同时灵活地解决多种用例，包括动态网络管理，容器可用性以及基于穆斯尔的分布中的可用性。

我正在研究一个旨在解决该空间中的问题的服务经理。特别是，它旨在成为OpenRC的合适替代品，目前为Alpine Linux发行权力提供支持，但这并不能提供Alpine需要的所有功能。由于其对小型和清洁软件的要求，并且在集装箱图像中越来越普遍，Alpine是一个典型的案例，在那里这个新的服务经理是有用的;但我预计该项目的利益远远超出高山。

这是一个长期努力，需要精确了解规范，软件设计的一定程度的技能和经验，以及大量的编码时间;我不认为它必须从一个更大的团队中受益，至少在编码方面，因为它仍然处于一个人可以完全理解的复杂程度 - 尽管如此，我价值外部输入（如技术讨论和用户体验）非常令人难以置信。但如果我在我的空闲时间工作，则无法在任何合理的时间范围内完成。由于这些原因，我正在寻找资金，以便能够全职工作;我相信对公司的好处，特别是使用高山Linux或类似的容器 - 合适的分布，远远超过了费用。本文件旨在解释项目的详细信息。

在术语如服务管理器和初始系统之类的术语周围完成了并不多的正式化，因此通常使用这些表达式而无需清楚地了解其语义。让＆＃39;首先定义这些术语。

init系统是由核心在启动时启动的软件组件集，并且其作业是将机器带到其完全运行状态，并完成所有配置以及其所有服务运行。

这些部件在概念上截然不同，但应该能够一起工作。例如，在没有详细的情况下，为了提供强烈的监督，流程监督系统需要与PID 1编程相关联。

大多数情况下，这些部分中的几个部分都在相同的软件套件中实现，这就是我们通常谈论Init系统的原因。 SYSVINIT，GNU / LINUX＆＃39; S传统的INIT系统，IS / SBIN / INIT和PID 1同时，还包括一个非常基本的过程主管。 （但它不包括服务管理器，这就是为什么它通常与Sysv-RC或OpenRC配对。）SystemD，UPSTART和MACOS＆＃39; S Launchd＆＃34;完成＆＃34; INIT系统，实现所有4个部分。

/ sbin / init和pid 1的重点是机器的早期启动，并且不符本文档范围。过程监督系统负责管理长期处理（守护进程）：确保它们始终以完全相同的环境开始，当它们在某些条件下将其死亡时，将其日志输出重新启动到适当的位置，提供接口发送给他们的信号而无需了解他们的PID等。它们也是严格来说，虽然我们必须提及他们的范围，但他们需要与服务经理密切互动。

Service Manager是从尚未运行的状态带来的组件，而且没有配置任何文件系统所在的状态，网络接口已启动，已初始化需要初始化的所有内容，管理员配置的所有服务都已启动和运行。相反，它还必须在admin需要时处理状态更改：停止服务，重新配置另一个服务。特别是，当管理员需要关机时，必须能够以有序的方式可靠地停止所有服务。

一个好的服务经理必须遵循适用于其设计，实现或其提供的功能的一定数量的约束。

服务管理器是系统基础架构软件，这意味着它以非常低的级别运行，并且整机操作依赖于它。这意味着：它必须非常可靠。这是通过具有清晰完整的语义来实现的，执行最低的操作量，尽可能少，并且确保DEV团队在所有时间内仍然完全可以理解，并且永远不会扩大控制。

它必须尽可能轻。申请不使用资源，而不是系统软件;重量级系统软件在旧计算机和嵌入式设备上无法使用，并在VM和容器中浪费。

它应该很容易引导。由于它是一个分发和＃39; S软件优惠的关键部分，并且在将分发到另一个架构或另一个平台上的分发时，它的第一封装之一如果，服务管理器应该具有尽可能少的构建时间依赖性。建造和安装它不应该是一个小时漫长的苦差。

服务管理器必须始终在同一环境中启动和停止服务，无论是在引导时还是通过管理员命令调用＆＃39; s。

服务经理必须使用流程监督系统绑定，以使守护进程管理和监控更容易。

服务管理器应保证系统可引导性。它应该提供一种机制，兽医在重新启动之前将vets更改为对启动时的服务集;一个制造的机制和＃34;改变被接受;如果您现在重新启动，机器将不会陷入不可恢复的状态，您将到达您想要的状态＆＃34;或＆＃34;更改无效，拒绝＆＃34;

服务管理器必须是并行：必须能够同时启动独立服务。这意味着它需要了解并维护它所知的所有服务之间的一组依赖项。传统上，这并未受到很多关注，因为适当的抚养管理和并行化是困难的;在拓扑上排序的列表之后，历史服务经理刚刚顺序地依次开始服务。然而，具有一个非常平行的服务经理，特别是在很长一段时间内开始和不必要地垄断CPU或不必要的闲置的诸斯的重型服务的存在。

服务管理器必须支持它开始的守护程序的准备通知。它确保服务只有其依赖项不仅生成的依赖项，而且还可以准备好（例如，确保守护程序实际创建，并在运行连接到它的客户端之前侦听套接字）。

服务管理器必须与外部事件接口，以允许用户定义动态启动和停止的服务，而无需在服务管理器配置中对每个可能的条件进行编码。典型使用这是在特定接口上侦听的网络守护程序：当接口出现时，必须启动它们，并且在接口下降时停止。以通用方式管理网络接口的状态太复杂了在服务管理器中处理的问题，并且最好委派给为此明确目的编写的网络管理员;并且当网络管理器检测到接口状态的变化时，它将事件发送到服务管理器，相应地反应。

服务管理器应支持声明性服务文件，该文件已显示的经验更直观，更少错误容易出错。编写脚本代码段是不可避免的，但那些片段应该尽可能小，并且最常见的服务功能（设置用户/组将运行，设置其环境等）应通过展示性语法来提供最小化错误。

服务经理应可用于容器以及虚拟机和真正的铁。越来越多地，整个服务层次结构的整个系统都在容器中运行，并且具有以有序方式启动容器内容的工具将改善众多容器图像的质量。这对于高山分布尤其如此，这通常用作容器图像的基础。

多年来，我对初学系统和服务经理做了很多研究;他们通常落入两类中的一个。

传统服务启动器。他们比经理更多的初学者，因为他们没有完全充实的依赖模型 - 他们＆＃39;重新用于在启动时启动服务并停止关闭时间，偶尔额外开始。所有这些都是顺序的，有利于简单;当添加并行性时，它往往是作为事后的经常品，它大大提高了代码复杂性。它们通常不旨在与监督系统合作：如果守护进程被杀死，他们就不会反应。

集成的Init系统。这些被编写为涵盖传统服务初学者的缺陷的尝试，并提供所有依赖管理，并行性，与监督集成以及实现完整初始系统所需的其他功能。不幸的是，他们＆＃39;重新集成（与模块化），复杂的野兽，并在其机制中嵌入很多政策，这表明难以与其他软件运行并想要超越机器上的所有管理任务而不是遵循＆＃34;一份工作，一个工具＆＃34;哲学。

Linux上的集成初始系统的主要示例显然是系统的;还有其他人，较少的侵入性和更少的普遍存在，如UPSTART（Ubuntu Precesoror到Systemd）。在MacOS上，Launchd陷入该类别。

这些选项都不令人满意。分布使他们有所作为：一些拥抱systemd - 而且这样做放弃了所有的希望永远摆脱它，或成为具有严重要求低资源使用或代码互动性的系统的合适选择;其他人使用OpenRC或类似软件抵抗拉动，并刮擦，并围绕缺乏功能。有些人像void Linux一样，甚至会选择不使用服务经理。 （他们使用一个很好的过程监督系统，但是必须脚跟他们的整个初学程序，这是他们的主要痛点之一。）

我已经对Init系统空间感兴趣了很长时间，并编写了自己的流程超级用户，S6和伴侣包S6-Linux-init，使其成为一个/ sbin / init和pid 1 。为了使S6成为完整的Init系统，需要服务管理器;这将是一个更复杂的努力，所以我写了一个小小的一个，s6 rc，作为原型 - 看看它会走多远，并了解设计服务时出现的问题的想法经理。

对于它的价值，我认为尝试取得成功。 S6-RC＆＃39;当前版本为0.5.2.1，它＆＃39; s的服务经理引擎在很多情况下工作得很好。它比OpenRC小，同时具有更多功能，而且比Systemd更快，同时仍然严格地掌握其发布顺序。它甚至采用了一些分布，即奥诺伦和Artix。

但是，它只是一种原型，并且缺乏关键的功能，然后才能令人满意地与已建立的玩家竞争：特别是，它仍然缺乏动态的事件管理，这使得它不适合与网络管理员集成，并且它缺乏友好的用户界面基于声明性服务文件，在考虑S6-RC作为所选服务经理之前，有几个分布已经清楚地发出信号。

因此，截至今天，没有服务经理，满足了分发的所有需求。这是一个＆＃34;选择你的毒药＆＃34;情况。

为了可视化这种情况，并且前进的道路，这里是一个比较表，显示OpenRC（作为传统服务发射器的示例），SystemD（作为集成初始系统的示例）和S6-RC（当前的原型版本）互相衡量。我们列出了我们上面详述的理想服务管理器的所有要求。

是的。 SystemD是C.然而，它只支持GNU LIBC，这可能是基于乐谱的分布的问题。

并不真地。 OPENRC可以为其守护进程产生基本的监督，但监事不会监督自己并提供一些福利。

不可以。配置更改可以使系统无法启动 - 甚至关闭。

并不真地。 OpenRC具有并行模式，从未正确运行，并由其开发人员积极泄解。

是的，太多：systemd作弊并忽略一些依赖项，以便更快地开始服务。 它会影响其可靠性和可预测性。 Systemd在内部支持动态事件，并提供自己的网络管理器，但不与其他软件进行界面。 不可以。0.5.2.1版本的S6-RC使用静态服务数据库，不会适应外部事件。 简单的服务可以纯粹声明地配置。 对于复杂的情况，仍然需要代码片段。 理论上是，但OpenRC嵌入了很多政策，使得难以适应和比利益更多的烦恼。 与所有系统一样，功能在那里，只要您完全选择进入模型; 这里，主机必须运行SystemD。 此外，Systemd不支持Musl，并且太大，无法适合容器。 S6-RC很小并将机制分开了策略，因此它可以编写特定于容器的服务集。

如图所示，尽管是为期3个月的1人项目，但S6-RC原型比OpenRC和Systemd在要求图表上更好。它是我们理想的最接近的。不幸的是，它仍然不适合作为可用于任何分布的灵活的用户友好的服务经理;为此，右下方的两种红色正方形需要变成绿色。这代表了大量的工作。

然而，在工作中，实际上会导致一块很好的软件，因为它只是一个实施问题。通过使用S6-RC原型作为最终软件的基础来实现理想服务管理器的所有目标仍然更容易，而不是调整和修改OpenRC或SystemD，因为这些缺陷是设计缺陷，不能通过添加更多代码或甚至重构来修复。

因此，我的命题是以S6-RC的真实，生产质量实现工作，保持声音设计，但添加了它所需的功能：

一个客户端 - 服务器模型，其中服务器，长寿过程维护当前状态和机器的所需状态，按照它们可用时执行所需的转换。

服务器的动态外部事件管理，具有专门的客户端程序，可以由外部实体（如网络管理器）调用，以向服务器通知服务器的事件。

用户友好的管理命令隐藏内部详细信息并遵循OpenRC，Service或SystemCtl的模型。用户将获得熟悉的命令界面。

声明性服务文件。单位文件的模型，其中用户可以只写键=值行而不是脚本，这是SystemD的响应成功 - 并且它也是良好的最终用户设计（如果解析器正确验证文件）也是良好的。它可以作为单独的用户界面图层进行，在更密闭的引擎之上运行。

目标是已知的，路径很清楚，里程碑被布局。但这是一个严重的项目，我想在我死之前看到它 - 如果我只能花钱，这是不太可能发生的空闲时间，我可以在需要维持自己的同时编写自由软件写作其他软件 - 可能更令人愉快，而且不那么自由。

这就是为什么我正在寻找资金，以便能够在这个全职工作。我的估计是它需要大约一年的工作，并应该给予投资的真正回报。在可能的福利中：

当其他分布开始采用S6-RC时，更快，更可靠的高山靴，以及更快，更可靠的全球靴子

最终，出现了高效，可靠和模块化的软件生态系统作为系统的真正替代品

但当然，真正的好处是，你能够说所有这一切都感谢你。

我的名字是Laurent Bercot，也称为某些圈子的Ska或Skarnet。我有一台计算机科学学位，并一直在与Linux一起使用，并从1999年开始参加自由软件运动。

我已经研究了监督系统和低级Linux用户空间二十年。 Init系统是我的专业领域;老实说，我认为我是最好的候选人之一，如果不是最好的话，写一个可以解决所有当前良好需求的服务经理，最终提供一个可靠的替代，功能明智的集成Init系统。

我已经写过C代码大约。 我的用户可以担保我的习惯提供质量代码，并具有广泛的文档。 Skarnet.org网站上提供了我写的免费软件; 核心是S6过程监控系统，该系统在今天使用的所有Docker容器中的大部分。 我参与了几种完整的软件社区，这些社区围绕着小型，紧凑的软件，例如Musl Libc，Alpine Linux发行版或Busybox项目。 我曾担任自由职业者C / Linux专家软件设计师和开发人员，而且只想在我关心的项目上做我的工作，而不是我最能做的。