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

#1 楼

2016 Update

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

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



抓住干草叉：Ubuntu在星期一切换到systemd（寄存器）

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

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

大多数信息下面的“命令和脚本”部分中的内容改编自该文章中使用的一些示例（已获得许可，就像Stack Exchange user contr根据知识共享署名-相同方式共享许可3.0）。

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

命令

运行su：



upstart：su


> systemd：machinectl shell


（请参见下面的“ su命令替换”部分）

运行屏幕：


< br upstart：screen


systemd-run --user --scope screen


（请参见下面的“意外终止后台进程”部分）

运行tmux：



upstart：tmux


systemd：systemd-run --user --scope tmux


（请参见下面的“意外终止后台进程”一节）

开始工作foo：



upstart： start foo


systemctl start foo


停止作业foo：



启动： stop foo


systemctl stop foo


重新启动作业foo：



upstart： restart foo


systemctl restart foo


上市工作：



启动：initctl list


系统化：systemctl status


检查作业foo的配置：



upstart ：init-checkconf /etc/init/foo.conf


systemd-analyze verify /lib/systemd/system/foo.service


列出作业的环境变量：




新贵：initctl list-env


系统：systemctl show-environment


设置作业的环境变量：




upstart：initctl set-env foo=bar


systemd：systemctl set-environment foo=bar


删除作业的环境变量：



upstart：initctl unset-env foo


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

脚本

用/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中：


添加新的“ machinectl shell”命令以实现类似su（1）的行为

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

他解释说：“您可以像以前一样使用su和sudo，但是不要指望它将完全发挥作用”。

现在，实现类似su行为的正式方法是：

machinectl shell

Lennart Poettering对其进行了进一步的解释
在有关问题＃825的讨论中：


“嗯，对此已经进行了很长时间的讨论，但是问题是
su应该做的事情还不清楚。 [...]
长话短说：su确实是一个残破的概念，它将为您提供一种外壳，可以使用它，但不是完整的
登录，不要误以为是。” -Lennart Poettering


另请参见：


Lennart Poettering将“ su”命令替换合并到systemd：Fedora Rawhide上的Test Drive
Systemd吸收“ su”命令功能

Systemd吸收“ su”命令（Hacker News）

意外终止后台进程

命令，如：


屏幕
tmux
nohup

不再按预期工作。例如，nohup是POSIX命令，以确保从会话注销后该进程继续运行。它不再适用于systemd。此外，还需要以特殊方式调用screen和tmux之类的程序，否则，与它们一起运行的进程将被杀死（而未杀死这些进程通常通常首先是运行screen或tmux的主要原因）。 br />
这不是一个错误，这是一个经过深思熟虑的决定，因此将来不太可能解决。这是Lennart Poettering对这个问题的评价：


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


有关更多信息，请参见：


Systemd默认默认开始杀死您的后台进程
Systemd v230在用户注销后杀死后台进程，中断屏幕，显示tmux
Debian Bug＃825394：systemd在用户注销后杀死后台进程


高级启动概念

systemd以一种向后工作的方式-在upstart作业中尽可能早地启动，而在systemd作业中则必须时启动。一天结束时，两个系统都可以以几乎相同的顺序启动相同的工作，但是您可以从相反的方向考虑，可以这么说。

这是Systemd的工作方式Upstart用户对此进行了解释：


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

systemd用于启动进程（单元）的模型是“基于懒惰的依赖关系”的。 e。仅当某个其他启动单元依赖该单元时，该单元才会启动。在引导过程中，systemd启动一个“根单元”
（default.target，可以在grub中覆盖），然后可传递地扩展并开始其依赖关系。一个新的单元需要添加自身作为引导顺序的一个单元的依赖项（通常是
multi-user.target），以便激活。


在发行版中的使用

现在根据Wikipedia提供一些最新数据：

默认情况下使用upstart发行版：



Ubuntu（从9.10到14.10）
Chrome OS
Chromium OS

默认情况下使用systemd的发行版：



Arch Linux-2012年10月以来

CentOS-2014年4月以来（7.14.04）

CoreOS-2013年10月sice（v94.0.0）

Debian -自2015年4月起（v8）

Fedora-自2011年5月起（v15）

Mageia-自2012年5月起（v2.0）

openSUSE -自2012年9月（v12.2）开始

Red Hat Enterprise Linux-自2014年6月（v7.0）

SUSE Linux Enterprise Server-自2014年10月（v12）

Ubuntu-自2015年4月起（v15.04）

（有关最新信息，请参阅Wikipedia）

发行版本不使用Upstart或systemd：



Devuan（Debian分支创建是由于Debian社区中的系统性争议导致Ian Jackson辞职而产生的）-专门宣传Init具有以下初始化系统（包括sinit，OpenRC，runit，s6和shepherd）的自由。

Void Linux-使用runit作为初始化系统和服务管理器

Gentoo-使用OpenRC


OS X-使用launchd



FreeBSD使用传统的BSD样式的init（不是SysV init）

NetBSD使用rc.d


DragonFly使用传统的init


OpenBSD使用此处描述的rc系统启动脚本


Alpine Linux（相对较新且鲜为人知的发行版，高度强调安全性正变得越来越流行-例如，Docker将其官方映像从Ubuntu转移到Alpine）使用OpenRC初始化系统

争议

过去，有人提出使用Debian的fork来避免systemd。创建了Devuan GNU + Linux-Debian的一个没有systemd的分支（感谢fpmurphy1在注释中指出了它）。

有关此争议的更多信息，请参见：


Debian在systemd上的官方立场
在systemd上的争议
2014年Debian Exodus声明：


众所周知，伊恩·杰克逊（Ian Jackson）提倡的Init GR Debian投票对保护Debian的遗产及其用户免受系统性的雪崩没有帮助。

这种情况预示着系统依赖性的锁定，即
实际上威胁到发展自由，对Debian及其上游和下游产生严重后果。

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




伊恩·杰克逊（Ian Jackson）辞职：


我即将从技术委员会辞职。效果。

继续在TC上代表项目的30-40％同意我的观点很重要
，我本人就是我
显然，在这一点上，这个数字太有争议了。我应该
尽量减少关于项目治理的个性化讨论。 [...]




Init Freedom：


Devuan诞生于关于决定用作
Debian的默认初始化系统。 Debian在systemd上的官方立场充斥着他人被揭穿的说法。感兴趣的
读者可以继续在systemd
争议中讨论这个热门话题。但是，我们鼓励您保持冷静，并保持
声音平和。在Devuan，我们对错误的编程更感兴趣，而不是回头。 [...]


已经创建了一些专门针对systemd争议的网站和文章：


Without-Systemd.org

Systemd-Free.org
基于Suckless的Init Freedom



关于Hacker News有很多有趣的讨论：


https://news.ycombinator.com/item?id=7728692
https://news.ycombinator.com/item?id=13387845
https：//news.ycombinator .com / item？id = 11797075
https://news.ycombinator.com/item?id=12600413
https://news.ycombinator.com/item?id=11845051
https://news.ycombinator.com/item?id=11782364
https://news.ycombinator.com/item?id=12877378
https://news.ycombinator.com/item？ id = 10483780
https://news.ycombinator.com/item?id=13469935

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

< bruckless NixOS教会正在寻找追随者

哲学

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

systemd的作用远不止于此。除了启动和停止服务外，它还管理密码，登录名，终端，电源管理，工厂重置，日志处理，文件系统挂载点，网络连接以及更多功能-有关某些功能，请参阅NEWS文件。

扩张计划

根据systemd的观点
Lennart Poettering于2014年在GNOME.asia上实现了什么，以及未来还有什么要发表的内容，以下是systemd的主要目标，已涉及的领域和仍在进行中的领域：

systemd目标：


我们的目标


将Linux从一小袋变成竞争性的通用操作系统。
构建Internet的下一代操作系统统一发行版之间毫无意义的差异
将创新带回到核心操作系统中。
台式机，服务器，容器，嵌入式，移动，云，集群等。 。 。这些领域比您想象的要紧密得多。
降低管理员的复杂性，可靠性而无需监督
一切自省的
自动发现，即插即用是关键
我们将损坏的地方修复，切勿将胶带粘在上面



已经覆盖的区域：


我们已经覆盖的区域：

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


正在进行的工作：


我们正在从事的工作：


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



此答案的范围

正如fpmurphy1在评论中指出的那样，“应该指出，systemd多年来的工作范围远远超出了只是系统启动的信息。”

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

更多信息

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



> upstart网站

systemd网站

Upped on Wikipedia

Systemd on Wikipedia

systemd的体系结构在Wikipedia

Linus Torvalds等在Linux的systemd（ZDNet）上

关于罗伯特·格雷厄姆（Robert Graham）关于systemd的争议
Init Freedom Campaign
从暴发户转向systemd的理由？

其他内容

LinOxide团队已经创建了Systemd vs SysV Init Linux速查表。

#2 楼

新贵公司和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预分配功能，许多守护进程将具有进行修补，以使systemd将FH传递给他们。

#3 楼

看到今天在Arch General ML上提到的systemd。因此，请仔细阅读。 H Online一如既往是Linux技术的绝佳来源，在这里我找到了开始研究Systemd作为SysV Init和Upstart替代产品的地方。但是，H Online的文章（在这种情况下）不是非常有用的阅读，它背后的真正用途是它提供了有用阅读的链接。

真正的答案是在systemd的声明中。这给出了SysV initd的问题以及新系统需要做什么的一些关键点，以减少启动。
并开始更多的并行操作。

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

该计划的另一部分似乎是不序列化文件系统，而是也按需挂载文件系统，这样您就不必等待/home/等（不要与/etc混淆）挂载，和/或fsck可以启动守护程序/和/var/等已经安装。它表示将为此目的使用autofs。

它的目标还在于创建.desktop样式的初始化描述符以代替脚本。这样可以避免大量的sh进程缓慢，甚至可以避免来自shell脚本中经常使用的sed和grep之类的更多进程。

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

另一个功能显然是能够根据时间事件（有规律地安排时间间隔或在特定时间）启动功能。这类似于crond和atd现在所做的。尽管有人告诉我它不支持用户“ cron”。就个人而言，这听起来是最没有意义的事情。我认为这是由不在多用户环境中工作的人编写/构想的，如果您是系统上的唯一用户，则不是cron用户，而不是不是以root用户身份运行。我每天都在多用户系统上工作，规则是始终以用户身份运行用户脚本。但是也许我没有他们的远见卓识，并且它绝对不会使我无法运行crond或atd，因此它不会伤害任何人，但我想是开发人员。

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

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


或更简单地说：用户刚刚启动D-Bus的事实绝不表示也应该启动NetworkManager（但这就是Upstart会做的事情）。相反，这是正确的：当用户要求使用NetworkManager时，这绝对表明D-Bus也应该启动（这肯定是大多数用户所期望的，对吧？）。

A好的init系统应该仅按需启动，然后按需启动。延迟地或并行地提前。但是，它的启动不应超出必要的范围，尤其是并非安装了所有可以使用该服务的东西。

我已经说过，在systemd的发布中将对此进行更全面的讨论。

#4 楼

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

因此，如果systemd启动了一个事物，它将把这个事物放入其自己的cgroup中，并且该进程没有（未特权）的意思。逃脱那个cgroup。结果是：


拥有许多用户的大型系统的管理员具有有效的新方法来识别恶意用户/进程。
CPU调度的优先级可以是确定更好，如“ Wonder autocgroup修补程序”所做的。

#5 楼

要对systemd进行非常详细的介绍，请从第一批设计草案开始（以及对现有init系统的详细评论，包括新贵，以及systemd建议如何修复它们），请转到其主页。随着时间的流逝，LWN上发表了几篇有关启动的文章。请注意，凡提及systemd（或pulseaudio）都会触发永无止境的火焰大战。

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

#6 楼

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