it-swarm.cn

Upstart和systemd的优点/缺点是什么?

似乎 systemd 是最新的热门 init 系统,与几年前的 pstart 相同。每个优点/缺点是什么?另外,它们各自与其他init系统相比如何?

187
tshepang

2016更新

这里的大多数答案都已经有5年了,所以是时候进行一些更新了。

Ubuntu以前默认使用upstart,但去年却放弃了它,转而使用systemd-请参阅:

因此,在Ubuntu Wiki上有一篇不错的文章 针对Upstart用户的Systemd -upstart和systemd之间的非常详细的比较,以及从upstart到systemd的过渡指南。

(请注意 根据Ubuntu Wiki ,您仍然可以默认情况下在当前版本的Ubuntu上运行upstart,方法是安装upstart-sysv并运行Sudo update-initramfs -u,但要考虑systemd项目的范围我不知道它在实际中是如何工作的,或者不知道systemd是否可以卸载。)

下面的“命令和脚本”部分中的大多数信息都是根据该文章中使用的一些示例改编而成的(它们很方便地获得许可,就像 (Creative Commons Attribution-ShareAlike 3.0 License )下的Stack Exchange用户贡献一样。 。

这是常见命令和简单脚本的快速比较,请参阅以下各节以获取详细说明。该答案是将问题中要求的基于Upstart的系统的旧行为与基于systemd的系统的新行为进行比较,但是请注意,标记为“ Upstart”的命令不一定是特定于Upstart的-它们通常是每个非系统Linux和Unix系统都通用。

指令

运行su:

  • pstart:su
  • systemd:machinectl Shell

(请参阅下面的“ su命令替换”部分)

运行画面:

  • pstart:screen
  • systemd:systemd-run --user --scope screen

(请参阅下面的“意外终止后台进程”部分)

运行tmux:

  • pstart:tmux
  • systemd:systemd-run --user --scope tmux

(请参阅下面的“意外终止后台进程”部分)

开始工作foo:

  • pstart:start foo
  • systemd:systemctl start foo

停止作业foo:

  • pstart:stop foo
  • systemd:systemctl stop foo

重新启动作业foo:

  • pstart:restart foo
  • systemd:systemctl restart foo

列出工作:

  • pstart:initctl list
  • systemd:systemctl status

检查作业foo的配置:

  • pstart:init-checkconf /etc/init/foo.conf
  • systemd:systemd-analyze verify /lib/systemd/system/foo.service

列出作业的环境变量:

  • pstart:initctl list-env
  • systemd:systemctl show-environment

设置作业的环境变量:

  • pstart:initctl set-env foo=bar
  • systemd:systemctl set-environment foo=bar

删除作业的环境变量:

  • pstart:initctl unset-env foo
  • systemd:systemctl unset-environment foo

日志

在upstart中,日志是/ var/log/upstart目录中的普通文本文件,因此您可以照常进行处理:

cat /var/log/upstart/foo.log
tail -f /var/log/upstart/foo.log

在systemd中,日志以内部二进制格式(而不是文本文件)存储,因此您需要使用journalctl命令来访问它们:

Sudo journalctl -u foo
Sudo journalctl -u foo -f

剧本

示例pstart脚本/etc/init/foo.conf编写:

description "Job that runs the foo daemon"
start on runlevel [2345]
stop on runlevel [016]
env statedir=/var/cache/foo
pre-start exec mkdir -p $statedir
exec /usr/bin/foo-daemon --arg1 "hello world" --statedir $statedir

示例系统脚本/lib/systemd/system/foo.service编写:

[Unit]
Description=Job that runs the foo daemon
Documentation=man:foo(1)
[Service]
Type=forking
Environment=statedir=/var/cache/foo
ExecStartPre=/usr/bin/mkdir -p ${statedir}
ExecStart=/usr/bin/foo-daemon --arg1 "hello world" --statedir ${statedir}
[Install]
WantedBy=multi-user.target

su命令替换

su命令替换已合并到请求请求#1022中的systemd中:

因为根据Lennart Poettering的说法, “ su确实是一个破烂的概念”

他解释说 “您可以像以前一样使用su和Sudo,但是不要指望它可以完全使用

现在,实现类似su行为的正式方法是:

machinectl Shell

在发行#825的讨论中,它进一步 由Lennart Poettering解释

“嗯,对此进行了长时间的讨论,但问题是,su应该做的事情还不清楚。[...]长话短说:su确实是一个破烂的概念。它将给您一种壳牌的感觉,也可以将其用于此目的,但这不是完整的登录名,也不应将其误认为一个登录名。” -Lennart Poettering

也可以看看:

意外杀死后台进程

像这样的命令:

不再按预期工作。例如,Nohup是POSIX命令,以确保从会话注销后该进程继续运行。 不再起作用 在systemd上。另外,还需要以特殊方式调用screentmux之类的程序 与它们一起运行的进程将被杀死 (而不会杀死这些进程)通常是首先运行屏幕或tmux的主要原因)。

这不是一个错误,这是一个经过深思熟虑的决定,因此将来不太可能解决。这就是Lennart Poettering 已说过 关于此问题:

在我看来,对于UNIX来说实际上是很奇怪的,它默认情况下允许任意用户代码在注销后保持不受限制的状态。许多操作系统人已经讨论了很长时间了,这应该是可能的,但肯定不是默认值,但是到目前为止,没有人敢将开关从默认设置转换为选项。注销后不清理用户会话不仅丑陋而且有些骇人听闻,而且还是安全问题。 systemd 230现在终于翻转了开关,并最终默认情况下在用户注销时正确清理了所有内容。

有关更多信息,请参见:

高级启动概念

以某种方式,systemd可以向后工作-在新贵的工作中尽快开始,而在systemd的工作中必须尽快开始。归根结底,两个系统都可以以几乎相同的顺序启动相同的作业,但是您可以从相反的方向来看。

这是 针对新贵用户的Systemd 的解释方式:

pstart的启动流程(工作)的模型是“基于贪婪事件的”,即。 e。启动事件发生的所有可用作业都将尽早启动。在启动过程中,新贵会综合一些启动事件,例如启动或rcS作为“树根”,早期的服务会在这些事件上启动,后来的服务会在前者运行时启动。一个新作业只需要将其配置文件安装到/ etc/init /中即可生效。

systemd的启动过程(单元)模型是“基于懒惰的依赖关系”的,即。 e。仅当某个其他启动单元依赖该单元时,该单元才会启动。在引导过程中,systemd启动一个“根单元”(default.target,可以在grub中覆盖),然后可传递地扩展并启动其依赖项。一个新的单元需要添加自身作为引导序列的一个单元的依赖关系(通常是multi-user.target)才能生效。

发行版中的用法

现在根据维基百科的一些最新数据:

默认情况下使用新贵的发行版:

默认情况下使用systemd进行分发:

(有关最新信息,请参阅 Wikipedia

既不使用Upstart也不使用systemd的发行版:

争议

过去 已提出Debian的fork来避免systemdDevuan GNU + Linux 已创建-Debian的一个fork,没有systemd(感谢 fpmurphy1 在注释中指出了它)。

有关此争议的更多信息,请参见:

就像你们中许多人已经知道的那样,由伊恩·杰克逊(Ian Jackson)提倡的Init GR Debian投票对于保护Debian的遗产及其用户免受系统性的雪崩袭击没有帮助。

这种情况预示着系统依赖的锁定,这实际上威胁着发展自由,并对Debian,其上游和下游造成严重后果。

CTTE设法通过依赖于sysvinit的微妙安装systemd来交换依赖关系并为我们赢得了时间,但是即使这个过程也很累并且充满了戏剧性。最终,一周前,伊恩·杰克逊(Ian Jackson)辞职。 [...]

我将从技术委员会辞职,立即生效。

尽管重要的是应继续在我的技术委员会中代表与我同意的项目的30-40%的观点,但我本人现在显然太有争议了,不能这样做。我应该退后一步,以减少有关项目治理的对话的个性化程度。 [...]

Devuan诞生于关于将其用作Debian的默认初始化系统的争议。 systemd上Debian的官方职位 充斥着 其他人已经揭穿 的主张。有兴趣的读者可以在 系统性争议 中继续讨论此热门话题。但是,我们鼓励您保持冷静,保持声音平和。在Devuan,我们对错误的编程比回头更感兴趣。 [...]

已经创建了一些有关systemd争议的网站和文章:

黑客新闻上有很多有趣的讨论:

在其他发行版中也可以观察到类似的趋势:

哲学

pstart遵循DOTADIW的Unix哲学-“做一件事情,做好事”。它替代了传统的init守护程序。除了启动和停止服务之外,它没有任何其他作用。其他任务则委托给其他专门的子系统。

systemd的作用远不止于此。除了启动和停止服务外,它还管理密码,登录名,终端,电源管理,工厂重置,日志处理,文件系统挂载点,网络连接等等-请参阅 [〜#〜]新闻[〜# 〜] 文件中的某些功能。

扩张计划

根据Lennart Poettering于2014年在GNOME.asia上发表的 关于Systemd的观点和未来的展望 ,这是systemd的主要目标,已经涵盖的领域和仍在进行中:

系统目标:

我们的目标

  • 将Linux从零碎的零碎变成竞争性的通用操作系统。
  • 构建Internet的下一代操作系统统一发行版本之间毫无意义的差异
  • 将创新带回到核心操作系统

  • 桌面,服务器,容器,嵌入式,移动,云,群集等。 。 。这些区域比您想象的更靠近

  • 降低管理员的复杂性,可靠性而无需监督
  • 一切自省
  • 自动发现,即插即用是关键
  • 我们将东西固定在损坏的地方,不要用胶带粘在上面

已经涵盖的领域:

我们已经介绍的内容:

初始化系统,日志记录,登录管理,设备管理,临时和易失性文件管理,二进制格式注册,背光保存/还原,rfkill保存/还原,引导图,预读,加密存储设置,EFI/GPT分区发现,虚拟机/容器注册,最小容器管理,主机名管理,语言环境管理,时间管理,随机种子管理,sysctl变量管理,控制台管理等。 。 。

工作正在进行中:

我们正在从事的工作:

  • 网络管理
  • 系统联网
  • 本地DNS缓存,mDNS响应器,LLMNR响应器,DNSSEC验证
  • 内核中的IPC
  • kdbus,sd-bus
  • 与NTP时间同步
  • 系统时间同步
  • 与容器的更多集成
  • 服务沙箱
  • 应用程序沙箱
  • 操作系统映像格式
  • 容器图片格式
  • 应用图片格式
  • 具有自动发现功能的GPT
  • 无状态系统,可实例化系统,出厂重置
  • / usr是操作系统
  • / etc是(可选)配置
  • / var为(可选)状态
  • 原子节点初始化和更新
  • 与云整合
  • 跨节点的服务管理
  • 可验证的操作系统映像
  • 一直到固件
  • 引导加载

这个答案的范围

正如注释中的 fpmurphy1 所说,“应该指出,多年来systemd的工作范围已远远超出了系统启动的范围。”

我试图在这里包括大多数相关信息。在这里,我将按照问题中的要求比较Upstart和systemd在用作init系统时的常见功能,我只提到systemd的功能超出了init系统的范围,因为它们无法与Startup进行比较,但是它们的存在很重要了解这两个项目之间的区别。应该检查相关文档以获取更多信息。

更多信息

可以在以下位置找到更多信息:

附加功能

LinOxide 团队创建了一个 Systemd与SysV Init Linux备忘单

92
rsp

新贵公司和systemd都试图解决传统SysV init系统的局限性。例如,某些服务需要在其他服务之后启动(例如,您必须在网络运行之前才能挂载NFS文件系统),但是SysV中处理此问题的唯一方法是在rc#.d目录中设置链接这样一个先于另一个。此外,添加或更改依赖项后,您可能需要重新编号所有内容。 Upstart和Systemd具有更智能的设置来定义需求。还有一个问题是,所有内容都是某种Shell脚本,而不是每个人都编写最佳的初始化脚本。这也会影响启动速度。

我可以看到systemd的一些优点:

  • 每个启动的进程都有自己的cgroup或特定的cgroup。
  • 预先为服务创建套接字和文件句柄,类似于xinetd为其服务所做的工作,从而使从属服务启动更快。例如,systemd将为/ dev/log保持syslog的打开文件句柄,并且发送到/ dev/log的后续服务将对其消息进行缓冲,直到syslogd准备好接管为止。
  • 运行较少的进程以实际启动服务。这意味着您无需编写Shell脚本来启动服务。这可以提高速度,并且(IMO)首先更容易设置。

我知道的一个缺点是,要利用systemd的套接字/ FH预分配,必须修补许多守护程序,以使FH由systemd传递给它们。

68
jsbillings

今天在 Arch General ML 上看到了systemd。因此,请仔细阅读。 H Online 一如既往是Linux技术的重要资料,也是我找到开始研究的地方的地方 系统化为SysV Init和Upstart替代品 。但是,H Online文章(在这种情况下)不是非常有用的阅读材料,它背后的真正用途是它提供了指向有用阅读内容的链接。

真正的答案是 systemd的公告 。这给出了SysV initd出了什么问题以及新系统需要做什么的一些关键点

  • 开始少。
  • 并开始更多并行工作。

它的主要计划似乎是仅在需要时启动服务,并启动该服务的套接字,以便需要该服务的服务可以在守护程序完全联机之前很长时间就连接到已创建的套接字。显然,套接字将保留少量的缓冲数据,这意味着在滞后期间不会丢失任何数据,它将在守护程序联机后立即进行处理。

该计划的另一部分似乎是不序列化文件系统,而是按需挂载文件系统,这样您就不必等待/home/等(请勿与/etc)挂载,和/或fsck可能以//var/等,已经安装。它表示将为此使用autofs。

它还具有创建.desktop样式初始化描述符可替代脚本。这样可以避免大量的sh进程,甚至更多的Shell脚本中经常使用的sedgrep之类的进程。

他们还计划在请求它们之前不启动某些服务,甚至可能在不再需要它们时将其关闭,例如,仅在使用蓝牙设备时才需要蓝牙模块和守护程序。给出的另一个示例是ssh守护程序。这是inetd能够做到的事情。就我个人而言,我不确定我是否喜欢这样,因为这可能意味着我确实需要它们时的延迟,而对于ssh,我认为这可能是一个安全漏洞,如果我的inetd受到损害,整个系统将会受到影响。但是,我被告知,使用它来破坏该系统是不可行的,如果我愿意,我可以按服务和其他方式禁用此功能。

显然,另一个功能将是基于时间事件启动的功能,该功能可以是定期安排的时间间隔,也可以是在特定时间。这类似于crondatd现在执行的操作。尽管有人告诉我它不支持用户“ cron”。就个人而言,这听起来是最没有意义的事情。我认为这是由不在多用户环境中工作的人编写/构想的,如果您是系统上的唯一用户,那么cron并没有太多用途,除了不是以root身份运行。我每天都在多用户系统上工作,规则是始终以用户身份运行用户脚本。但是也许我没有他们的远见卓识,而且它绝不会使我无法运行crondatd,因此它不会对任何人造成伤害,但我想开发人员。

Systemd的最大缺点是必须修改某些守护程序才能充分利用它。它们现在可以工作,但是如果专门为其套接字模型编写它们,则它们会更好地工作。

似乎在大多数情况下,systemd与新贵有关的人民问题是事件系统,他们认为这没有意义或不必要。也许他们的话说得最好。

或更简单地说:用户刚刚启动D-Bus的事实绝不表示也应该启动NetworkManager(但这就是Upstart会做的事情)。相反,这是正确的:当用户要求使用NetworkManager时,这绝对表明D-Bus也应该启动(这肯定是大多数用户所期望的,对吗?)。
一个好的初始化系统应该仅按需启动,然后按需启动。延迟地或并行地提前。但是,它的启动时间不应超过必要的时间,尤其是并非已安装的所有可以使用该服务的东西。

正如我已经说过的那样,在 systemd的公告 中对此进行了更全面的讨论。

29
xenoterracide

你们大多数人忘记的一件事是 cgroups 中的流程组织。

因此,如果systemd启动了一个东西,它将把这个东西放在它自己的cgroup中,并且该进程没有逃脱该cgroup的(无特权)手段。这就是后果:

  • 具有许多用户的大型系统的管理员具有有效的新方法来识别恶意用户/进程。
  • 可以通过 “ Wonder autocgroup patch” 更好地确定CPU调度的优先级。
11
enaut

要对systemd进行非常详细的介绍,请从第一个设计草案开始(以及对现有init系统的详细评论,包括新贵,以及systemd建议如何修复它们),请转到 主页 。随着时间的流逝,关于 [〜#〜] lwn [〜#〜] 发表了几篇有关启动的文章。请注意,凡提及systemd(或pulseaudio)都会触发永无休止的战争。

IMVHO(作为Fedora用户)我很满意非常。解决当前Linux系统的复杂性早就该行了。 Fedora使用了新贵一段时间,但它从未脱离过成为sysvinit的理想替代品的地位,它几乎运行了未更改的初始化脚本。其简化引导配置的承诺是以再次手动设置相互依赖关系为代价的,但这是行不通的。系统化的数字本身就是依赖的(或者只允许在不考虑依赖的情况下开始工作,他们会自行整理)。另一个很大的优势(有人说这是一个严重的劣势)是它利用了特定于Linux的功能(特别是cgroups允许隔离守护程序及其所有后代,因此易于监视,限制资源或将其杀死)一组;还有许多其他)。

8
vonbrand

日志记录-Systemd实际上类似于WinSXS文件夹,用于记录内容,除非您手动删除或减小文件大小,否则它会创建副本副本,否则它将继续占用您的驱动器。我称它为引导加载程序cookie。

3
Bert