系统管理员喜爱 systemd 的 5 个理由

Systemd 的速度和易用性使其成为管理现代 Linux 系统的流行方式。
115 位读者喜欢这篇文章。
Woman sitting in front of her laptop

kris krüg

正如系统管理员所知,现代计算机上发生了很多事情。应用程序在后台运行,自动化事件等待在特定时间触发,日志文件被写入,状态报告被传递。传统上,这些不同的进程一直使用一系列 Unix 工具进行管理和监控,效果显著且效率极高。然而,现代计算机是多样化的,本地服务与容器化应用程序并行运行,可以轻松访问云和它们运行的集群、实时进程以及比以往更多的数据需要处理。

用户期望有一种统一的管理方法,而对于繁忙的系统管理员来说,这是一种有用的奢侈品。对于这项重要的任务,系统守护进程,或 systemd,被开发出来并迅速被所有主要的 Linux 发行版采用。

当然,systemd 不是管理 Linux 系统的唯一方法。还有许多替代的 init 系统,包括 sysvinit、OpenRC、runit、s6 甚至 BusyBox,但 systemd 将 Linux 视为一个统一的数据集,旨在通过强大的工具进行一致地操作和查询。对于繁忙的系统管理员和许多用户来说,systemd 的速度和易用性是一项重要功能。以下是五个原因。

启动管理

启动 Linux 计算机可能是一件非常罕见的事情,如果您希望如此。当然,在服务器领域,正常运行时间通常以而不是几个月或几周来计算。笔记本电脑和台式机往往会频繁地关闭和启动,尽管即使是这些设备也更可能是被挂起或休眠,而不是被关闭。无论哪种方式,自上次启动事件以来的时间都可以作为计算机健康检查的一种会话管理器。这是一种限制在监控系统或诊断问题时查看哪些数据的有用方法。

如果您不记得上次启动计算机的时间,您可以使用 systemd 的日志工具 journalctl 列出启动会话

$ journalctl --list-boots
-42 7fe7c3... Fri 2020-12-04 05:13:59 - Wed 2020-12-16 16:01:23 
-41 332e99... Wed 2020-12-16 20:07:39 - Fri 2020-12-18 22:08:13 
[...]
-1 e0fe5f... Mon 2021-03-29 20:47:46 - Mon 2021-03-29 21:59:29
 0 37fbe4... Tue 2021-03-30 04:46:13 - Tue 2021-03-30 10:42:08

最新的启动会话出现在列表底部,因此您可以将输出通过管道传输到 tail,仅获取最新的启动。

左侧的数字(在本例中为 42、41、1 和 0)是每个启动会话的索引号。换句话说,要仅查看特定启动会话的日志,您可以使用其索引号作为参考。

日志查看

查看日志是推断系统信息的重要方法。日志提供了计算机在您未直接监督的情况下进行的许多活动的历史记录。您可以查看服务何时启动、定时作业何时运行、哪些服务在后台运行、哪些活动失败等等。最常见的初始故障排除步骤之一是查看日志,使用 journalctl 可以轻松完成此操作

$ journalctl --pager-end

--pager-end 选项(或简写 -e)从 journalctl 输出的末尾开始查看日志,因此您必须向上滚动才能查看较早发生的事件。

Systemd 维护着一个错误和消息“目录”,其中充满了错误记录、可能的解决方案、指向支持论坛的指针以及开发者文档。这可以为日志事件提供重要的上下文,否则日志事件可能会成为消息海洋中令人困惑的闪烁,或者更糟糕的是,可能完全被忽视。要将错误消息与解释性文本集成,您可以使用 --catalog 选项(或简写 -x

$ journalctl --pager-end --catalog

为了进一步限制您需要筛选的日志输出,您可以指定要查看哪个启动会话的日志。由于每个启动会话都已索引,因此您可以使用 --boot 选项指定特定会话,并且仅查看适用于该会话的日志

$ journalctl --pager-end --catalog --boot 42

您还可以查看特定 systemd 单元的日志。例如,要排查安全外壳 (SSH) 服务的问题,您可以指定 --unit sshd 以仅查看适用于 sshd 守护进程的日志

$ journalctl --pager-end \
--catalog --boot 42 \
--unit sshd

服务管理

systemd 的首要任务是启动您的计算机,它通常会及时、高效且有效地完成此任务。但是永无止境的任务是服务管理。按照设计,systemd 确保您想要运行的服务确实在您的会话期间启动并继续运行。这非常强大,因为理论上即使崩溃的服务也可以在无需您干预的情况下重新启动。

您帮助 systemd 管理服务的界面是 systemctl 命令。使用它,您可以查看定义服务的单元文件

$ systemctl cat sshd
# /usr/lib/systemd/system/sshd.service
[Unit]
Description=OpenSSH server daemon
Documentation=man:sshd(8) man:sshd_config(5)
After=network.target sshd-keygen.target
Wants=sshd-keygen.target

[Service]
Type=notify
EnvironmentFile=-/etc/crypto-policies/back-ends/opensshserver.config
EnvironmentFile=-/etc/sysconfig/sshd
ExecStart=/usr/sbin/sshd -D $OPTIONS $CRYPTO_POLICY
ExecReload=/bin/kill -HUP $MAINPID
KillMode=process
Restart=on-failure
RestartSec=42s

[Install]
WantedBy=multi-user.target

大多数单元文件都位于 /usr/lib/systemd/system/ 中,但与许多重要配置一样,我们鼓励您使用本地更改来修改它们。也有一个用于此目的的界面

$ systemctl edit sshd

您可以查看服务当前是否处于活动状态

$ systemctl is-active sshd
active
$ systemctl is-active foo
inactive

同样,您可以使用 is-failed 查看服务是否失败。

启动和停止服务非常直观

$ systemctl stop sshd
$ systemctl start sshd

启用服务在启动时启动也很简单

$ systemctl enable sshd

添加 --now 选项以启用服务在启动时启动或为当前会话启动服务。

定时器

很久以前,当您想在 Linux 上自动化任务时,规范的工具是 cron。cron 命令仍然有用武之地,但也有一些引人注目的替代方案。例如,anacron 命令是一个通用的、类似 cron 的系统,能够运行在停机期间原本会错过的任务。

计划事件只不过是在特定时间激活的服务,因此 systemd 管理着一个名为定时器的类似 cron 的功能。您可以列出活动定时器

$ systemctl list-timers
NEXT                          LEFT       
Tue 2021-03-30 12:37:54 NZDT  16min left [...]
Wed 2021-03-31 00:00:00 NZDT  11h left [...]
Wed 2021-03-31 06:42:02 NZDT  18h left [...]

3 timers listed.
Pass --all to see loaded but inactive timers, too.

您可以像启用服务一样启用定时器

$ systemctl enable myMonitor.timer

目标

目标是 systemd 矩阵的最后一个主要组件。目标由单元文件定义,与服务和定时器相同。目标也可以以相同的方式启动和启用。目标的独特之处在于,它们以任意重要的方式将其他单元文件分组在一起。例如,您可能希望启动到文本控制台而不是图形桌面,因此存在 multi-user 目标。但是,multi-user 目标只是没有桌面单元文件作为依赖项的 graphical 目标。

简而言之,目标是一种简单的方法,您可以将服务、定时器甚至其他目标收集在一起,以表示计算机的预期状态。

实际上,在 systemd 中,重启、关机或关闭操作只是另一个目标。

您可以使用 list-unit-files 选项列出所有可用目标,并使用设置为 target--type 选项进行约束

$ systemctl list-unit-files --type target

使用 systemd 掌控一切

现代 Linux 使用 systemd 进行服务管理和日志内省。它为从个人 Linux 系统到企业服务器的所有系统提供了一种现代机制,用于监控和轻松维护。您使用得越多,systemd 就变得越舒适、可预测和直观,并且您越能发现系统的不同部分是如何相互关联的。

要更好地了解 systemd,您必须使用它。为了舒适地使用它,下载我们的速查表并经常参考它。

接下来阅读

学习喜爱 systemd

systemd 是所有进程之母,负责将 Linux 主机提升到可以进行高效工作的状态。

Seth Kenlon
Seth Kenlon 是一位 UNIX 极客、自由文化倡导者、独立多媒体艺术家和 D\&D 爱好者。他曾在电影和计算机行业工作,通常同时进行。

27 条评论

这里有一位不喜欢 systemd 的系统管理员。

我也不是真的很喜欢它,但本文的来源是 Red Hat。

Red Hat 吹嘘他们自己的工具?不可思议!

回复 ,作者 MartyMonroe

我认为您可能对此解读过度了。我在我的 RHEL 服务器上使用 systemd(不在我的工作站上,我的工作站十多年来一直运行 Slackware),并且我撰写文章以推广开源。我这样做与谁在项目的 repo 中拥有最多的提交无关(但为了记录,我没有做过 `git blame` 来实际计算谁拥有最多的提交以及哪个实体雇用他们)。

仅此而已。

回复 ,作者 Teh Billeh

我认为,如果能听到更多关于人们使用其他 init 系统的过程(“您使用什么 init 系统,以及您使用什么工具链来管理它?”),那将是很有意义的。如果您有兴趣讲述其他 init 系统的故事,请提交一篇文章!

回复 ,作者 spooky

systemd 可能是我有史以来用过的最糟糕的 init。他们所说的关于它的所有优点都可以通过 grep、sed、awk 和 perl 等命令轻松完成。这甚至还没有涉及到它的真正问题,比如二进制日志文件、混乱的启动顺序、无法使用的 init 脚本,以及最糟糕的功能蔓延。

回复 ,作者 MartyMonroe

虽然本文很好地总结了 systemd 的优点,但它完全忽略了它引入的严重问题。如果它仍然是最初计划的系统管理工具集,我(以及其他人,我怀疑)会很乐意使用它。不幸的是,深度集成导致几乎不可能从依赖链中将其分离出来,并且似乎正在稳步扩展其范围。
Distrowatch 上 2015 年 4 月 1 日的文章令人担忧地接近现实,并且似乎并没有变得不那么现实!

我听到了您所说的。我也更喜欢极端的模块化,但标准化是有用的,而 init 系统在历史上并没有做到这一点。在我看来,systemd 提供了一个可预测的基础,许多其他应用程序可以在此基础上构建,并且处于相当低的级别。我曾担任系统管理员,也曾为 Linux 开发软件;我很欣赏 systemd 为前者提供的工具,并且我更喜欢它为后者提供的统一性。

我不是发行版维护者,但在我看来,大多数主要发行版都已迁移到 systemd,这说明了很多问题。您无法让发行版在任何事情上达成一致,但大型发行版都采用了 systemd。话虽如此,我并非在所有系统上都运行 systemd,因此仍然有很多选择。我不认为这种情况会改变。

回复 ,作者 David Tillotson

systemd 太可怕了。无论您怎么美化它,它仍然是一头猪。

您使用哪个 init 系统?您应该考虑写一篇关于它的文章,以及您为什么喜欢它。我总是对人们使用的工具以及它使他们能够做什么感到着迷。分享知识吧!

回复 ,作者 spooky

对于那些不同意本文前提的人,可以选择 Devuan。

https://www.devuan.org/

它是 Debian 的成熟分支,保留了 init 系统选择。

感谢您的文章,Seth!即使 systemd 在我的系统上,我对它的工作原理也不太了解。我总是渴望学习更多。

很高兴听到这篇文章对您有所启发,Don!您(和许多其他用户)每天都在使用 systemd,但对它知之甚少且不太关心,这绝对证明了 systemd 的价值。这一定意味着事情正在按预期进行,这是一个很棒的状态。

回复 ,作者 Don Watkins

systemd....

- 首席开发人员自言自语,当有人提出有效问题时,他会疯狂地揉搓耳朵。
- 不再将其任务视为 init 系统,而是一个完全独立的生态系统,其中包含过多的集成和依赖于它的应用程序。
- 它的成功是基于通过已经建立并拥有庞大用户群的大型发行版强制使用它。他们别无选择,只能接受其发行版开发团队的决定。
- 在实际使用中,查找错误或损坏的进程(尤其是在应用程序启动时)是一场噩梦。如果不是这样,那么众多的 Linux 和开发论坛就不会充斥着关于同一件事的 systemd 问题。认真地说,看看解释基本 OpenRC 或 SysV 启动脚本需要多少教程,然后与用户无法通过 systemd 启动 Python 脚本、在服务中维护以及轻松发现和理解错误的线程数量进行比较。

Seth,这篇文章写得很好而且很详细,就像您的大部分文章一样,但是建议其他人撰写关于他们使用的 init 系统的文章是在回避评论者试图告诉您的内容。他们没有使用其他 init,他们使用的是 systemd,因为他们别无选择;而且您已经知道这一点,可以用它来为您的文章辩护。

在 systemd 之前,您可以随意更换 init。当然,您必须重写您的配置文件和启动脚本,但这不会阻止您安装应用程序。例如,Devuan 应该是在删除了 systemd 的 Debian。尝试在其中安装 10 个 .deb 软件包,看看有多少可以正常工作。从另一个方面来看,看看有多少用户可以在第一次在自己编写的脚本或从源代码软件包中使他们的 systemd 服务文件正常工作,而以前这就像一行 cron 作业和一个 bash 脚本一样容易。

好吧,您已经看穿了我的虚张声势。我会写文章的。敬请期待。

回复 ,作者 Moz

呵呵,我很期待它们。如果您有机会,请先写 OpenRC;另一方面,MX Linux 最近似乎越来越受欢迎,因此也许必须是 SysV,这也将满足我们这些仍在运行 Slackware 的人的需求。

回复 ,作者 sethkenlon

奇怪的是您提到了这一点。今天早上我真的刚刚下载了 MX,目的是将其用作第一篇文章的基础。但我也渴望重新审视 OpenRC,所以谁知道我实际上会先写什么!

回复 ,作者 Moz

说得好。我有一个系统最终被我*放弃*了,因为 systemd 在其上的启动不可靠,而且论坛上没有人愿意真正伸出援手 - 而这来自一个自第 6 版以来就一直在使用 UNIX 并且学到了很多新东西的人。Systemd 是一场*灾难*。

回复 ,作者 Moz

我不太关心哪个 init 系统在运行,只要它们能工作,而且在大多数情况下,systemd 对我来说只是工作正常,也许我只是幸运。至于创建新的单元文件等等,是的,与仅仅拼凑一个 bash 脚本相比,存在一个学习曲线,但对于某些人来说,它们都涉及相同程度的神秘魔法。幸运的是,我还没有从头开始创建很多,当我把它们整理好后,它们似乎就能正常工作。systemd 仍然存在问题并且正在渗透到所有领域吗?当然,但正如 Seth 指出的那样,至少它的界面相对一致,并且某些功能可以简单地关闭并使用替代方案。我发现适应和尽可能多地了解我管理的系统比抱怨改变(即使它被认为是为改变而改变)更有成效。这只是我的个人看法。

bash 如何不一致?systemd 最糟糕的部分远远超出了 init 脚本。它是二进制日志文件。功能蔓延,您为什么要 init 来进行日志记录?或者解析主机名。

systemd 只是很愚蠢。

回复 ,作者 iceburg

信息不错

非常感谢 Seth,感谢您为帮助理解 systemd 这个不太容易的世界所付出的努力。与其诅咒这个工具,不如尝试驾驭它!

mv systemd some-other-reality

知识共享许可协议本作品根据知识共享署名-相同方式共享 4.0 国际许可协议获得许可。
© . All rights reserved.