systemd最大的误解

自从我们首次提议将systemd 纳入发行版以来，它就经常出现在许多论坛、邮件列表和会议上。在这些讨论中，人们经常会听到一些关于 systemd 的谣言，这些谣言被一遍又一遍地重复，但不断重复肯定不会带来任何真相。让我们花点时间来揭穿其中的一些谣言：

误解：systemd 是整体式的。

如果您在启用所有配置选项的情况下构建 systemd，您将构建 69 个单独的二进制文件。这些二进制文件都用于不同的任务，并且由于多种原因而被整齐地分开。例如，我们在设计 systemd 时考虑到了安全性，因此大多数守护进程都以最小权限运行（例如，使用内核功能）并且仅负责非常特定的任务，以最大限度地减少它们的安全面和影响。此外，systemd 比任何以前的解决方案都更能并行化启动。这种并行化是通过并行运行更多进程来实现的。因此，将 systemd 很好地分成许多二进制文件和进程至关重要。事实上，许多这样的二进制文件[1]被很好地分开，以至于它们在 systemd 之外也非常有用。

一个包含 69 个独立二进制文件的软件包很难被称为 整体式。然而，与之前的解决方案不同的是，我们在一个 tarball 中发送更多组件，并在具有统一发布周期的单个存储库中维护它们。

误解：systemd 关心的是速度。

是的，systemd 速度很快（有人知道在 900 毫秒内完成用户空间启动吗？ ），但这主要是做正确事情的副作用。事实上，我们从未真正坐下来优化 systemd 的最后一点性能。相反，我们实际上经常故意选择稍慢的代码路径，以保持代码的可读性。这并不意味着速度对我们来说无关紧要，但将 systemd 的速度降低到它的速度肯定是一个误解，因为这肯定不是我们目标列表的首要任务。

误解：systemd 的快速启动对于服务器来说无关紧要。

这完全不是事实。许多管理员实际上热衷于减少维护时段的停机时间。在高可用性设置中，如果故障机器能够快速恢复，那就太好了。在具有大量虚拟机或容器的云设置中，启动缓慢的代价会随着实例数量的增加而成倍增加。花费数分钟的 CPU 和 IO 来缓慢地启动数百台虚拟机或容器会大大降低系统的密度，甚至会消耗更多的能源。启动缓慢的代价可能相当昂贵。然后，快速启动容器允许您实现诸如套接字激活容器之类的逻辑，从而让您大幅提高云系统的密度。

当然，在许多服务器设置中，启动确实无关紧要，但 systemd 应该覆盖整个范围。是的，我知道通常是服务器固件在启动时花费了最多的时间，而操作系统无论如何都比它快，但是，systemd 仍然应该覆盖整个范围（见上文……），不，并非所有服务器都有如此糟糕的固件，当然也不是虚拟机和容器，它们也是一种服务器。[2]

误解：systemd 与 shell 脚本不兼容。

这完全是假的。我们只是不将它们用于启动过程，因为我们认为它们不是用于该特定目的的最佳工具，但这并不意味着 systemd 与它们不兼容。您可以轻松地将 shell 脚本作为 systemd 服务运行，甚至您可以将用任何语言编写的脚本作为 systemd 服务运行，systemd 根本不关心您的可执行文件里面有什么。此外，我们大量使用 shell 脚本来达到我们自己的目的，用于安装、构建、测试 systemd。您可以将脚本放在早期启动过程中，将它们用于正常服务，您可以在最晚关机时运行它们，几乎没有任何限制。

误解：systemd 很难。

这也是完全无稽之谈。systemd 平台实际上比传统 Linux 简单得多，因为它将系统对象及其依赖项统一为 systemd 单元。配置文件语言非常简单，我们摆脱了冗余配置文件。我们为系统的大部分配置提供统一的工具。该系统比传统 Linux 的复杂程度要低得多。我们还有相当全面的文档（全部链接在主页上），几乎涵盖了 systemd 的每个细节，不仅涵盖了面向管理员/用户的界面，还包括开发人员 API。

systemd 当然有一个学习曲线。一切都是如此。然而，我们倾向于相信，对于大多数人来说，理解 systemd 实际上比基于 Shell 的启动更简单。你觉得我们这么说很惊讶吗？好吧，事实证明，Shell 不是一种容易学习的语言，它的语法晦涩难懂。systemd 单元文件要容易理解得多，它们不暴露编程语言，但本质上是简单和声明性的。话虽如此，如果你有 shell 经验，那么是的，采用 systemd 需要一点学习。

为了使学习变得简单，我们努力提供与以前解决方案的最大兼容性。但不仅如此，在许多发行版上，您会发现一些传统工具现在甚至会在执行您要求的操作时告诉您如何使用较新的工具以更好的方式执行操作。

无论如何，我们得出的结论是，systemd 可能是最简单的系统了，而且我们努力让它易于学习。但是，是的，如果你了解 sysvinit，那么采用 systemd 需要一点学习，但坦率地说，如果你掌握了 sysvinit，那么 systemd 对你来说应该很容易。

误解：systemd 不是模块化的。

根本不是这样。在编译时，您可以使用多个 配置开关来选择要构建的内容和不构建的内容。我们记录了如何更详细地选择您需要的内容，而不仅仅是我们的配置开关。

这种模块化与 Linux 内核的模块化并不完全不同，在 Linux 内核中，您可以在编译时单独选择许多功能。如果内核对您来说足够模块化，那么 systemd 也应该非常接近。

误解：systemd 仅适用于桌面。

这当然不是事实。我们试图通过 systemd 覆盖与 Linux 本身几乎相同的范围。虽然我们关心桌面用途，但我们也同样关心服务器用途和嵌入式用途。你可以打赌，如果它不是管理服务器上服务的最佳选择，Red Hat 不会将其作为 RHEL7 的核心部分。

许多公司的人员都在研究 systemd。汽车制造商将其安装在汽车上，Red Hat 将其用作服务器操作系统，GNOME 则利用其许多界面来改进桌面。玩具、太空望远镜和风力涡轮机中都可以看到它的身影。

我最近研究的大多数功能可能主要与服务器相关，例如容器支持、资源管理或安全功能。我们已经很好地涵盖了桌面系统，并且有许多公司正在为嵌入式系统进行 systemd 开发，有些甚至提供咨询服务。

误解：systemd 是由于 NIH 综合症而创建的。

事实并非如此。在开始开发 systemd 之前，我们一直在推动 Canonical 的 Upstart 得到广泛采用（Fedora/RHEL 也曾使用过它）。然而，我们最终得出结论，它的设计在核心上存在缺陷（至少在我们看来：最根本的是，它将依赖关系管理留给了管理员/开发人员，而不是在代码中解决这个难题），如果核心出现问题，你最好替换它，而不是修复它。但这绝不是唯一的原因，还有其他因素，比如围绕它的许可/贡献协议混乱。不过，NIH 并不是原因之一…… [3]

误解：systemd 是一个 freedesktop.org 项目。

好吧，systemd 确实托管在 fdo 上，但 freedesktop.org 只不过是一个代码和文档存储库。几乎任何程序员都可以在那里申请一个存储库并将他的东西转储到那里（只要它与自由系统的基础设施有些相关）。这里没有阴谋集团，没有“标准化”方案，没有项目审查，什么都没有。它只是一个不错的、免费的、可靠的存储库存放地。在这方面，它有点像 SourceForge、github、kernel.org，只是不是商业性的，也没有过分的要求，因此是存放我们的东西的好地方。

所以是的，我们将我们的东西托管在 fdo 上，但这个神话的隐含假设是，有一群人开会并就未来自由系统的样子达成一致，这完全是错误的。

误解：systemd 不是 UNIX。

这当然有一定道理。systemd 的源代码中没有一行代码源自原始 UNIX。但是，我们的灵感来自 UNIX，因此 systemd 中有大量 UNIX。例如，UNIX 的“一切皆文件”理念反映在 systemd 中，所有服务在运行时都在内核文件系统 cgroupfs 中公开。然后，UNIX 的原始功能之一是多​​席位支持，基于内置终端支持。然而，文本终端几乎不是您如今与计算机交互的最新方式。通过 systemd，我们恢复了原生多席位 支持，但这次完全支持当今的硬件，包括图形、鼠标、音频、网络摄像头等，所有这些都是全自动的、热插拔的，无需配置。事实上，systemd 的设计是一套集成工具，每个工具都有各自的用途，但一起使用时不仅仅是各部分的总和，这几乎是 UNIX 哲学的核心。然后，我们处理项目的方式（即在单个 git 存储库中维护大部分核心操作系统）比 Linux 上的方式更接近 BSD 模型（与 Linux 不同，它是一个真正的 UNIX）（其中大部分核心操作系统保存在单个 CVS/SVN 存储库中）。

归根结底，UNIX 对每个人来说都是不同的。对于我们 systemd 维护者来说，它是我们从中获取灵感的东西。对于其他人来说，它是一种宗教，就像其他世界宗教一样，对它有不同的解读和理解。有些人根据特定的代码遗产来定义 UNIX，其他人则将其视为一组想法，其他人将其视为一组命令或 API，甚至其他人将其视为行为的定义。当然，不可能让所有这些人都满意。

归根结底，某事物是否是 UNIX 的问题并不重要。技术上的卓越并非 UNIX 所独有。对我们来说，UNIX 是一个主要影响因素（甚至是最大的影响因素），但我们也受到其他影响。因此，在某些领域，systemd 会非常 UNIX 化，而在其他领域，则不那么 UNIX 化。

误解：systemd 很复杂。

这话确实有一定道理。现代计算机非常复杂，因此其上运行的操作系统也必须很复杂。但是，systemd 肯定不会比相同组件的先前实现更复杂。相反，它更简单，冗余更少（见上文）。此外，基于 systemd 构建简单的操作系统所需的软件包比传统 Linux 要少得多。更少的软件包使构建系统变得更容易，摆脱了相互依赖性以及每个组件的不同行为。

误解：systemd 过于臃肿。

好吧，臃肿当然有很多不同的定义。但在大多数定义中，systemd 可能与臃肿相反。由于 systemd 组件共享一个通用的代码库，它们倾向于为通用的代码路径共享更多的代码。这里有一个例子：在传统的 Linux 设置中，sysvinit、start-stop-daemon、inetd、cron、dbus 都实施了一种方案，以在某个希望是干净的环境中执行具有各种配置选项的进程。在 systemd 上，所有这些的代码路径、配置解析以及实际执行都是共享的。这意味着更少的代码、更少的错误空间、更少的内存和缓存压力，因此是一件非常好的事情。而作为副作用，您实际上可以获得更多的功能…

如上所述，systemd 也非常模块化。您可以在构建时选择需要哪些组件，不需要哪些组件。因此，人们可以专门选择他们想要的“膨胀”程度。

构建 systemd 时，它只需要三个依赖项：glibc、libcap 和 dbus。就是这样。它可以使用更多依赖项，但这些完全是可选的。

所以，是的，无论你怎么看，它确实不是 臃肿的。

误解：systemd 仅适用于 Linux，对 BSD 来说并不好。

完全错误。BSD 的人们几乎对 systemd 不感兴趣。如果 systemd 是可移植的，这不会改变任何事情，他们仍然不会采用它。世界上的其他 Unix 也是如此。Solaris 有 SMF，BSD 有自己的“rc”系统，他们总是将它与 Linux 分开维护。init 系统非常接近整个操作系统的核心。因此，这些其他操作系统通过其核心用户空间来定义自己。假设我们只要使它可移植，他们就会采用我们的核心用户空间，这是完全没有任何根据的。

误解：systemd 仅适用于 Linux，因此 Debian 无法将其作为默认设置。

Debian 在其发行版中支持非 Linux 内核。systemd 无法在这些内核上运行。但这是个问题吗？这会妨碍他们采用系统作为默认内核吗？其实不然。将 Debian 移植到这些其他内核的人愿意投入大量时间进行移植工作，他们设置测试和构建系统，并为他们的目标修补和构建大量软件包。与此相比，维护 systemd 单元文件和打包服务的经典 init 脚本的工作量微不足道，尤其是因为这些脚本通常已经存在。

误解：如果 systemd 的维护者愿意，它可以移植到其他内核。

这根本不是事实。将 systemd 移植到其他内核是不可行的。我们只是使用了太多特定于 Linux 的接口。对于少数情况，人们可能会在其他内核上找到替代品，某些功能人们可能想要关闭，但对于大多数情况，这实际上是不可能的。这是一个很小且非常不全面的列表：cgroups、fanotify、umount2()、/proc/self/mountinfo（包括通知）、/dev/swaps（相同）、udev、netlink、 /sys的结构、/proc/$PID/comm、/proc/$PID/cmdline、/proc/$PID/loginuid、/proc/$PID/stat、/proc/$PID/session、/proc/$PID/exe、/proc/$PID/fd、tmpfs、devtmpfs、capability、各种命名空间、各种prctl()、大量ioctl、mount()系统调用及其语义、selinux、audit、inotify、statfs、O_{D}IRECTORY、O_{N}OATIME、/proc/$PID/root、waitid()、SCM_CREDENTIALS、SCM_RIGHTS、mkostemp()、/dev/input、…

不，如果你看一下这个列表并挑选出几个你能想到的其他内核上明显对应的内核，然后再想一想，看看你没有选择的其他内核，以及替换它们的复杂性。

误解：systemd 不可移植是毫无理由的。

胡说！我们使用 Linux 特有的功能是因为我们需要它来实现我们想要的功能。Linux 拥有 UNIX/POSIX 所没有的众多功能，我们希望让用户能够使用这些功能。这些功能非常有用，但前提是它们必须以友好的方式呈现给用户，而这正是我们对 systemd 所做的。

误解：systemd 使用二进制配置文件。

不知道是谁想出了这个疯狂的神话，但这绝对不是真的。systemd 几乎完全通过简单的文本文件进行配置。您还可以使用内核命令行和环境变量更改一些设置。其配置中没有任何二进制文件（甚至没有 XML）。只是简单、易读的文本文件。

误解：systemd 的功能逐渐增多。

嗯，systemd 确实比以前覆盖了更多领域。它不再只是一个 init 系统，而是构建操作系统的基本用户空间构建块，但我们小心翼翼地确保大多数功能都是可选的。您可以在编译时关闭很多功能，甚至可以在运行时关闭更多功能。因此，您可以自由选择想要的功能扩展量。

误解：systemd 强迫您做某事。

systemd 不是黑手党。它是免费软件，你可以用它做任何你想做的事，包括不使用它。这与“强迫”完全相反。

误解：systemd 使得 syslog 无法运行。

事实并非如此，我们在引入日志时仔细确保所有数据也都传递到正在运行的任何 syslog 守护程序。事实上，如果发生更改，那么只有该 syslog 会获得比以前更完整的数据，因为我们现在涵盖了早期启动内容以及任何系统服务的 STDOUT/STDERR。

误解：systemd 不兼容。

我们竭尽全力提供与 sysvinit 的最佳兼容性。事实上，绝大多数 init 脚本在未经修改的情况下都可以在 systemd 上正常工作。然而，实际上确实存在一些不兼容性，但我们会尝试记录这些不兼容性并解释如何处理它们。最终，每个实际上不是 sysvinit 本身的系统都会与它存在一定程度的不兼容性，因为它不会共享完全相同的代码路径。

我们的目标是确保将各个发行版之间的差异保持在最低限度。这意味着单元文件通常可以在您编写它时所在的发行版之外的其他发行版上正常工作，这比传统的 init 脚本有了很大的改进，因为这些脚本之间存在许多不兼容性，因此很难编写出可以在多个 Linux 发行版上运行的脚本。

误解：由于使用 D-Bus，systemd 无法编写脚本。

不对。systemd 提供的几乎每个 D-Bus 接口都可以在命令行工具中使用，例如systemctl、 loginctl、 timedatectl、 hostnamectl、 localectl 等。您可以从 shell 脚本轻松调用这些工具，它们使用易于使用的命令从命令行打开几乎整个 API。

话虽如此，D-Bus 实际上绑定了世界上几乎所有的脚本语言。即使在 shell 中，您也可以使用dbus-send 或gdbus调用任意 D-Bus 方法。无论如何，这提高了脚本编写能力，因为各种脚本语言都对 D-Bus 提供了良好的支持。

误解：systemd 要求您使用一些神秘的配置工具，而不是允许您直接编辑配置文件。

根本不是这样。我们提供一些配置工具，使用它们可以为你提供一些额外的功能（例如，所有设置的命令行完成！），但根本不需要使用它们。如果你愿意，你总是可以直接编辑相关文件，这是完全支持的。当然，有时你需要在编辑配置后明确重新加载某些守护进程的配置，但对于大多数 UNIX 服务来说，这几乎是正确的。

误解：systemd 不稳定且有缺陷。

根据我们的数据，肯定不是。我们一直在密切监控 Fedora 错误跟踪器（以及其他一些跟踪器）。对于操作系统的这样一个核心组件来说，错误数量非常少，特别是如果您不考虑我们为该项目跟踪的大量 RFE 错误。我们非常擅长将 systemd 排除在发行版的阻止错误列表之外。我们的开发周期相对较快，主要是增量更改以保持高质量和高稳定性。

误解：systemd 不可调试。

错误。有些人试图暗示 shell 是一个很好的调试器。其实不然。在 systemd 中，我们为您提供实际的调试功能。例如：交互式调试、详细跟踪、在启动期间屏蔽任何组件的能力等等。此外，我们还为其提供了文档。

它确实具有很好的可调试性，毕竟我们自己的开发工作需要它。但有一点我们要承认：它使用不同的调试工具，但我们认为有更适合此目的的工具。

误解：systemd 为了改变而改变。

完全不是事实。我们所做的更改几乎完全出于技术原因，我们会在各种文档、维基页面、博客文章、邮件列表公告中解释这些原因。我们努力避免做出不兼容的更改，如果确实如此，我们会尝试详细记录原因和方法。如果您对某事感到疑惑，请直接询问我们！

误解：systemd 是 Red Hat 独有的项目，是一些聪明的开发人员的私有财产，他们利用它来向世界推销他们的观点。

不对。目前，有 16 名黑客拥有 systemd git 树的提交权限。这 16 人中只有 6 人受雇于 Red Hat。另外 10 人来自 ArchLinux、Debian、Intel，甚至来自 Canonical、Mandriva、Pantheon，还有一些拥有完全提交权限的社区人士。他们经常提交大东西、重大更改。然后，有 374 个人在我们的树中修补了补丁，他们也来自不同的公司，具有不同的背景，其中许多人在树中修补了不止一个补丁。关于我们想将 systemd 带向何方的讨论都是公开进行的，在我们的 IRC 频道（ freenode 上的#systemd，我们随时欢迎您）、我们的邮件列表和公共黑客大会（例如我们下一场在布尔诺举行的黑客大会，欢迎您参加）上。我们定期参加各种会议，收集反馈，解释我们在做什么以及为什么这样做，很少有人这样做。我们维护博客，参与社交网络（事实上我们在 Google+ 上有一些非常有趣的内容，我们的Google+ 社区也非常活跃），并尽力解释我们做事的原因和方式，听取反馈并找出当前的问题所在（例如，根据这些反馈，我们编制了一份关于 systemd 的经常听到的误解列表…）。

大多数 systemd 贡献者可能都对一个好的操作系统应该是什么样子有一个大致的想法，并渴望实现它。然而，由于该项目的本质是开源的，并且扎根于社区，systemd 正是人们想要的，如果这不是他们想要的，那么他们可以用补丁和代码来推动方向，如果这不可行，那么还有许多其他选择可以使用，systemd 永远不会是唯一的。

systemd 的一个目标是统一分散的 Linux 环境。我们试图消除核心操作系统各个领域中各种发行版之间的许多无意义差异。作为其中的一部分，我们有时会采用以前仅由其中一个发行版使用的方案，并将其推至 systemd 默认的水平，试图让每个人都慢慢地采用同一套基本配置。但这绝不是排他性的，如果发行版愿意，它们可以继续偏离这一目标，但是，如果它们最终使用得到良好支持的默认配置，它们的工作就会变得容易得多，并且它们可能会获得一两个功能。现在，事实证明，我们实际上更多地采用 Debianisms 的方案，而不是 Fedoraisms/Redhatisms，因为这是 systemd 最支持的方案。例如，运行 systemd 的系统现在通常将其主机名存储在/etc/hostname中，这曾经是 Debian 特有的，现在已在各个发行版中使用。

不过，有一件事我们可以承认，我们有时会很自作聪明。我们试图在开口说话时做好准备，以便能够用事实来支持我们的说法。这可能会让我们看起来像个自作聪明的人。

但总的来说，是的，systemd 的一些更有影响力的贡献者为 Red Hat 工作，但他们是少数，systemd 是一个健康、开放的社区，有不同的兴趣、不同的背景，只是由一些粗略的想法统一起来，决定旅程应该去哪里，这是一个以代码和设计为重的社区，绝对与公司无关。

误解：systemd 不支持将/usr从根目录分离。

毫无意义。自一开始，systemd 就支持 其configure脚本的–with-rootprefix=选项，该选项允许您告诉 systemd 整齐地划分早期启动所需的内容和稍后启动所需的内容。所有这些逻辑都已完全存在，我们会在 systemd 的构建系统中保持其最新状态。

当然，我们仍然认为在/usr unavailable 的情况下进行实际启动不是一个好主意，但我们在构建系统中对此提供了很好的支持。这不会解决您将遇到的方案固有问题，但您不能将此归咎于 systemd，因为在 systemd 中我们对此提供了很好的支持。

误解：systemd 不允许您替换其组件。

事实并非如此，除了极少数例外，您可以关闭和替换 systemd 的几乎任何部分。这些例外（例如 journald）通常允许您同时运行替代方案，同时与其很好地协作。

误解：systemd 使用 D-Bus 而不是套接字，这使其不透明。

这种说法本身就已经自相矛盾了：D-Bus 也使用套接字作为传输方式。因此，每当使用 D-Bus 发送某些内容时，套接字也会用于此。D-Bus 主要是通过这些套接字发送消息的标准化序列化。如果有什么不同的话，那就是这使其更加透明，因为这种序列化有据可查、易于理解，并且有许多跟踪工具和语言绑定。这与各种经典 UNIX 守护进程用于本地通信的通常的自有协议非常不同。

嗯，我是不是写了我只是想揭穿“一些”谣言？也许这些谣言不止一些……无论如何，我希望我能够澄清一些误解。感谢您抽出时间。

脚注

[1] 例如，systemd-detect-virt、 systemd-tmpfiles、 systemd-udevd。

[2] 此外，我们正在努力尽自己的一份力量来改善这种情况。通过在 systemd 的启动输出中更突出地显示固件的启动时性能，我们希望让固件编写者感到惭愧，从而清理他们的内容。

[3] 无论如何，猜猜哪个项目包含一个库“lib nih ”——Upstart 还是 systemd？[4]

[4] 提示：它不是 systemd！