关于 systemd 的 30 个最大误区

误解1：systemd 是单体的。

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

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

误解2：systemd 是关于速度的。

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

误解3：systemd 的快速启动与服务器无关。

这完全不是真的。许多管理员实际上热衷于在维护窗口期间减少停机时间。在高可用性设置中，如果发生故障的机器能够很快恢复，那就太好了。在具有大量 VM 或容器的云设置中，缓慢启动的价格会随着实例数量的增加而倍增。在数百个虚拟机或容器的非常缓慢的启动上花费几分钟的 CPU 和 IO 会大大降低系统的密度，见鬼，它甚至会花费你更多的能量。慢靴在经济上可能相当昂贵。然后，容器的快速启动允许您实现诸如套接字激活容器之类的逻辑，从而使您能够大幅增加云系统的密度。

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

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

这完全是假的。我们只是不将它们用于启动过程，因为我们相信它们不是用于该特定目的的最佳工具，但这并不意味着 systemd 与它们不兼容。您可以轻松地将 shell 脚本作为 systemd 服务运行，哎呀，您可以将用任何语言编写的脚本作为 systemd 服务运行，systemd 丝毫不在意可执行文件中的内容。此外，我们大量使用 shell 脚本用于我们自己的目的，用于安装、构建、测试 systemd。您可以在早期启动过程中粘贴脚本，将它们用于正常服务，您可以在最晚关闭时运行它们，几乎没有限制。

误解5：systemd 很难。

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

systemd 肯定有一个学习曲线。什么都行。但是，我们愿意相信对于大多数人来说，理解 systemd 实际上比基于 Shell 的引导更简单。惊讶我们这么说？嗯，事实证明，Shell 不是一门很好学的语言，它的语法既神秘又复杂。systemd 单元文件更容易理解，它们不公开编程语言，但本质上简单且具有声明性。话虽如此，如果您对 shell 有经验，那么是的，采用 systemd 需要一些学习。

为了让学习更容易，我们努力提供与以前解决方案的最大兼容性。但不仅如此，在许多发行版中，您会发现一些传统工具现在甚至会告诉您——在执行您所要求的操作时——如何使用较新的工具以一种可能更好的方式来实现.

无论如何，要点可能是 systemd 可能像这样的系统一样简单，并且我们努力使其易于学习。但是，是的，如果您了解 sysvinit，那么采用 systemd 需要一些学习，但坦率地说，如果您掌握了 sysvinit，那么 systemd 对您来说应该很容易。

误解6：systemd 不是模块化的。

根本不是真的。在编译时，您有许多 配置开关来选择要构建的内容和不构建的内容。而我们的文件，你如何在选择的更多详细信息，你需要什么，超越我们的配置开关。

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

误解7：systemd 仅适用于台式机。

这当然不是真的。使用 systemd，我们尝试覆盖与 Linux 本身几乎相同的范围。虽然我们关心桌面使用，但我们也关心服务器使用和嵌入式使用的方式几乎相同。您可以打赌，如果 Red Hat 不是管理服务器上的服务的最佳选择，它不会成为 RHEL7 的核心部分。

许多公司的人都在使用 systemd。汽车制造商将其组装到汽车中，Red Hat 将其用于服务器操作系统，而 GNOME 则使用其许多界面来改进桌面。你可以在玩具、太空望远镜和风力涡轮机中找到它。

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

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

这不是真的。在我们开始研究 systemd 之前，我们一直在推动 Canonical 的 Upstart 被广泛采用（Fedora/RHEL 也使用了一段时间）。然而，我们最终得出的结论是，它的设计在其核心本质上存在缺陷（至少在我们看来：最根本的是，它将依赖管理留给管理员/开发人员，而不是在代码中解决这个难题），如果有什么核心错误你最好更换它，而不是修复它。但这并不是唯一的原因，还有其他一些因素在起作用，例如许可/贡献协议。

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

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

所以是的，我们在 fdo 托管我们的东西，但是这个神话的隐含假设是有一群人见面然后就未来的自由系统的样子达成一致，这完全是假的。

误解10：systemd 不是 UNIX。

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

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

最终，某个东西是否是 UNIX 的问题无关紧要。技术上的优秀并不是 UNIX 独有的。对我们来说，UNIX 是一个主要的影响因素（见鬼，最大的一个），但我们也有其他影响。因此，在某些领域 systemd 将非常 UNIXy，而在其他领域则少一些。

误解11：systemd 很复杂。

这当然有一定的道理。现代计算机是复杂的野兽，因此在其上运行的操作系统也必须很复杂。但是，systemd 肯定不会比相同组件的先前实现更复杂。相反，它更简单，冗余更少（见上文）。此外，基于 systemd 构建一个简单的操作系统将比传统的 Linux 包含更少的包。更少的包可以更轻松地构建您的系统，摆脱相互依赖关系以及所涉及的每个组件的许多不同行为。

误解12：systemd 很臃肿。

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

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

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

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

误解13：systemd 只支持 Linux 对 BSD 不利。

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

误解14：systemd 仅支持 Linux，因此 Debian 不可能将其作为默认值。

Debian 在其发行版中支持非 Linux 内核。systemd 不会在这些上运行。不过，这是一个问题吗，这是否会阻碍他们采用系统作为默认设置？并不真地。将 Debian 移植到这些其他内核的人们愿意投入时间进行大量移植工作，他们建立了测试和构建系统，并为他们的目标修补和构建了许多软件包。与此相比，为打包服务维护 systemd 单元文件和经典 init 脚本的工作量可以忽略不计，尤其是因为这些脚本通常已经存在。

误解15：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，能力，各种命名空间，各种使用prctl（）秒，无数的读写控制，在安装（）系统调用及其语义、selinux、审计、inotify、statfs、O_{D}IRECTORY、O_{N}OATIME、/proc/$PID/root、waitid()、SCM_CREDENTIALS、SCM_RIGHTS、mkostemp()、/dev/input、…

不，如果您查看此列表并挑选出少数您可以在其他内核上想到明显对应项的地方，然后再想一想，并查看您没有挑选的其他内核，以及替换它们的复杂性。

误解16：systemd 无缘无故不可移植。

废话！我们使用 Linux 特定的功能是因为我们需要它来实现我们想要的。Linux 有很多 UNIX/POSIX 没有的功能，我们希望为用户提供这些功能。这些功能非常有用，但前提是它们实际上以友好的方式向用户公开，这就是我们使用 systemd 所做的。

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

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

误解18：systemd 是一个功能蠕变。

好吧，systemd 肯定涵盖了它过去的更多领域。它不再只是一个 init 系统，而是构建操作系统的基本用户空间构建块，但我们小心翼翼地确保大多数功能都是可选的。您可以在编译时关闭很多功能，甚至在运行时关闭更多功能。因此，您可以自由选择所需的功能爬行量。

误解19：systemd 强迫你做某事。

systemd 不是黑手党。它是自由软件，您可以随心所欲地使用它，这包括不使用它。这几乎与“强迫”相反。

误解20：systemd 使运行 syslog 变得不可能。

不是真的，我们在引入日志时仔细确保所有数据也传递给任何正在运行的系统日志守护程序。事实上，如果有什么变化，那么只有那个 syslog 现在获得比以前更完整的数据，因为我们现在涵盖早期启动内容以及任何系统服务的 STDOUT/STDERR。

误解21：systemd 不兼容。

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

我们的目标是确保各种分布之间的差异保持在最低限度。这意味着单元文件通常在与您编写它的发行版不同的发行版上工作得很好，这比经典的 init 脚本有了很大的改进，这些脚本很难以在多个 Linux 发行版上运行的方式编写，因为它们之间存在许多不兼容性.

误解22：systemd 不可编写脚本，因为它使用 D-Bus。

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

也就是说，D-Bus 实际上绑定了世界上几乎所有已知的脚本语言。即使在 shell 中，您也可以使用dbus-send 或gdbus调用任意 D-Bus 方法。如果有的话，由于 D-Bus 在各种脚本语言中的良好支持，这提高了脚本能力。

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

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

误解24：systemd 不稳定且有问题。

当然不是根据我们的数据。很长一段时间以来，我们一直在密切监视 Fedora 错误跟踪器（和其他一些）。对于操作系统的这样一个核心组件来说，错误的数量非常少，特别是如果您忽略了我们为项目跟踪的众多 RFE 错误。我们很好地将 systemd 排除在发行版的阻止程序错误列表之外。我们有一个相对较快的开发周期，主要是增量更改以保持高质量和稳定性。

误解25：systemd 不可调试。

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

它当然可以很好地调试，毕竟我们自己的开发工作需要它。但是我们会告诉你一件事：它使用不同的调试工具，不过我们相信更适合此目的的工具。

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

非常不真实。我们几乎完全有做出更改的技术原因，我们在各种文档、维基页面、博客文章、邮件列表公告中解释了它们。我们努力避免进行不兼容的更改，如果我们这样做，我们会尝试详细记录原因和方式。如果您对某些事情感到疑惑，请咨询我们！

误解27：systemd 是一个 Red-Hat 独有的项目，是一些聪明的开发者的私有财产，他们用它来将他们的观点推向全世界。

不对。目前，有 16 名黑客拥有对 systemd git 树的提交权限。在这 16 名员工中，只有 6 名受雇于 Red Hat。其他 10 位成员来自 ArchLinux、Debian、英特尔，甚至来自 Canonical、Mandriva、Pantheon 和一些拥有完全提交权的社区成员。他们经常犯下大事，重大改变。然后，我们的树中有 374 个人有补丁，他们也来自许多不同的公司和背景，其中许多人在树上有不止一个补丁。关于我们要将 systemd 带到哪里去的讨论是在公开的、我们的 IRC 频道（freenode上的#systemd，你永远是weclome）、我们的邮件列表和公共黑客节（例如我们在布尔诺的下一个）上进行的， 你被邀请了）。我们定期参加各种会议，收集反馈，解释我们在做什么以及为什么，很少有人这样做。我们维护博客，参与社交网络（我们实际上在 Google+ 上有一些非常有趣的内容，我们的Google+ 社区也非常活跃。），并努力解释我们做事的原因和方式，并倾听反馈并找出当前的问题所在（例如，根据反馈，我们编制了这份关于 systemd 的经常听到的神话列表…）。

大多数 systemd 贡献者可能分享的是一个好的操作系统应该是什么样子的粗略想法，以及实现它的愿望。然而，由于项目的本质是开源的，并且植根于社区 systemd 正是人们想要的，如果这不是他们想要的，那么他们可以用补丁和代码来推动方向，如果不是的话可行，那么还有许多其他选项可以使用，systemd 从来都不是排他性的。

systemd 的一个目标是稍微统一分散的 Linux 环境。我们试图摆脱核心操作系统各个领域中各种发行版的许多更无意义的差异。作为其中的一部分，我们有时会采用以前仅由一个发行版使用的方案，并将其推到 systemd 的默认级别，试图温和地将每个人推向相同的基本配置集。这从来都不是排他性的，如果他们愿意，发行版可以继续偏离，但是，如果他们最终使用支持良好的默认设置，他们的工作会变得容易得多，他们可能会获得一两个功能。现在，事实证明，我们实际上更频繁地采用了 Debianisms 而不是 Fedoraisms/Redhatisms 作为 systemd 支持的最佳方案的方案。例如，/etc/hostname，以前是 Debian 特有的，现在可以跨发行版使用。

不过，我们会答应你的一件事，我们有时可以是聪明的驴。每当我们开口时，我们都会努力做好准备，以便能够用事实来支持我们所声称的。这可能会让我们看起来像个聪明人。

但总的来说，是的，一些更有影响力的 systemd 贡献者为 Red Hat 工作，但他们是少数，systemd 是一个健康、开放的社区，具有不同的兴趣、不同的背景，只是由一些粗略的想法统一起来，其中旅行应该去，一个社区，其中代码及其设计很重要，当然不是公司隶属关系。

误区28：systemd 不支持从根目录拆分/usr。

废话。从一开始 systemd 就支持其配置脚本的 --with-rootprefix=选项，它允许您告诉 systemd 整齐地拆分早期启动所需的内容和稍后启动所需的内容。所有这些逻辑都完全存在，我们会在 systemd 的构建系统中将其保持在最新状态。

当然，我们仍然不认为使用/usr不可用来实际启动是一个好主意，但是我们在我们的构建系统中很好地支持这一点。这不会解决您将全面遇到的方案的固有问题，但您不能将其归咎于 systemd，因为在 systemd 中，我们对此提供了很好的支持。

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

不正确，除了极少数例外，您几乎可以关闭和替换 systemd 的任何部分。并且这些异常（例如 journald）通常允许您并排运行替代方案，同时与它很好地合作。

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

这种说法本身已经是矛盾的：D-Bus 也使用套接字作为传输。因此，每当使用 D-Bus 发送某些内容时，也会使用套接字。D-Bus 主要是通过这些套接字发送的消息的标准化序列化。如果有的话，这使它更加透明，因为这种序列化有很好的文档记录和理解，并且有许多跟踪工具和语言绑定。这与各种经典 UNIX 守护程序用于本地通信的通常的本地协议非常不同。