这里的大多数答案都已经有5年了，所以是时候进行一些更新了。
Ubuntu以前默认使用upstart，但去年却放弃了它，转而使用systemd-请参阅：
因此，在Ubuntu Wiki上有一篇不错的文章《针对Upstart用户的Systemd》 -非常详细地比较了upstart和systemd，以及从upstart到systemd的过渡指南。
（请注意，根据Ubuntu Wiki，默认情况下，您仍然可以通过安装upstart-sysv和运行在新版本的Ubuntu上运行upstart，sudo update-initramfs -u但考虑到systemd项目的范围，我不知道它在实践中如何工作，或者systemd是否在可以卸载。）
下面的“命令和脚本”部分中的大多数信息都是根据该文章中使用的一些示例改编而成的（就像在Creative Commons Attribution-ShareAlike 3.0许可下的Stack Exchange用户贡献一样，已被方便地许可）。
这是常见命令和简单脚本的快速比较，请参阅以下各节以获取详细说明。该答案是按照问题中的要求，将基于Upstart的系统的旧行为与基于systemd的系统的新行为进行比较，但是请注意，标记为“ Upstart”的命令不一定是特定于Upstart的-它们通常是对于每个非系统化Linux和Unix系统都是通用的。
sumachinectl shell（请参阅下面的“ su命令替换”部分）
screensystemd-run --user --scope screen（请参阅下面的“意外杀死后台进程”部分）
tmuxsystemd-run --user --scope tmux（请参阅下面的“意外杀死后台进程”部分）
start foosystemctl start foostop foosystemctl stop foorestart foosystemctl restart fooinitctl listsystemctl statusinit-checkconf /etc/init/foo.confsystemd-analyze verify /lib/systemd/system/foo.serviceinitctl list-envsystemctl show-environmentinitctl set-env foo=barsystemctl set-environment foo=barinitctl unset-env foosystemctl 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
示例的systemd脚本编写为/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命令替换并入systemd上拉请求＃1022：
因为根据Lennart Poettering的说法，“ su确实是一个破碎的概念”。
他解释说：“您可以像以前一样使用su和sudo，但不要指望它能完全正常工作”。
现在，实现类似su行为的官方方法是：
machinectl shell
Lennart Poettering在发布问题＃825的讨论中作了进一步解释：
“嗯，对此进行了长时间的讨论，但是问题在于，su应该做的事情还不清楚。 ，也可以将其用于此目的，但这不是完整的登录名，也不应误认为是一个完整的登录名。” -Lennart Poettering
也可以看看：
像这样的命令：
不再按预期工作。例如，nohup是POSIX命令，以确保从会话注销后该进程继续运行。它不再适用于systemd。同样，像这样的程序screen以及tmux需要以特殊方式调用的程序，否则与它们一起运行的进程将被杀死（而未杀死这些进程通常通常首先是运行screen或tmux的主要原因）。
这不是一个错误，这是一个经过深思熟虑的决定，因此将来不太可能得到解决。这就是伦纳特·珀特林说这个问题：
在我看来，对于UNIX来说实际上是很奇怪的，它默认情况下允许任意用户代码在注销后保持不受限制的状态。许多操作系统人已经讨论了很长时间，这应该是可能的，但肯定不是默认的，但是到目前为止，没有人敢将开关从默认设置转换为选项。注销后不清理用户会话不仅很丑陋，而且有些骇人听闻，而且还是一个安全问题。现在，systemd 230最终翻转了开关，并最终默认情况下在用户注销时正确清理了所有内容。
有关更多信息，请参见：
以某种方式systemd向后工作-在新贵的工作中尽快开始，而在systemd的工作中必须尽快开始。归根结底，两个系统都可以以几乎相同的顺序启动相同的工作，但是可以说，它是从相反的方向看的。
这是Systemd for Upstart用户的解释方式：
Upstart用于启动流程（作业）的模型是“基于贪婪事件的”，即，发生启动事件的所有可用作业都应尽早启动。在启动过程中，新贵将一些启动事件（例如启动或rcS）作为“树根”进行合成，早期服务在这些事件上启动，后来服务在前者运行时启动。一个新作业只需要将其配置文件安装到/ etc / init /中即可生效。
systemd用于启动过程（单元）的模型是“基于懒惰的依赖关系”的，即，仅当某个其他启动单元依赖于该单元时，该单元才会启动。在引导过程中，systemd启动一个“根单元”（default.target，可以在grub中覆盖），然后可传递地扩展并启动其依赖项。一个新的单元需要添加自身作为引导序列（通常是multi-user.target）的一个单元的依赖关系，以使其变为活动状态。
现在根据维基百科的一些最新数据：
（有关最新信息，请参阅维基百科）
在过去，有人提出了Debian的fork来避免systemd。该Devuan GNU + Linux的创建-的Debian的一个分支，而不systemd（感谢fpmurphy1指点出来的评论）。
有关此争议的更多信息，请参见：
就像你们中许多人已经知道的那样，伊恩·杰克逊（Ian Jackson）提倡的Init GR Debian投票对于保护Debian的遗产及其用户免受系统性的雪崩袭击并没有帮助。
这种情况预示着系统依赖的锁定，这实际上威胁到了发展自由，并对Debian，其上游和下游产生了严重的后果。
CTTE设法通过依赖于sysvinit的微妙安装systemd来交换依赖关系并为我们赢得了时间，但即使这个过程也很累人，而且充满了戏剧性。最终，一周前，伊恩·杰克逊（Ian Jackson）辞职了。[...]
我将从技术委员会辞职，即刻生效。
尽管重要的是应继续在我的技术委员会中代表我同意的项目的30-40％的意见，但我本人现在显然太有争议了，不能这样做。我应该退后一步，以减少有关项目治理的对话的个性化程度。[...]
Devuan出于对将其用作Debian的默认初始化系统的争议而诞生。Debian在systemd上的官方立场充斥着其他人被揭穿的说法。有兴趣的读者可以在The systemd争议中继续讨论这个热门话题。但是，我们鼓励您保持冷静，保持声音平和。在Devuan，我们对错误的编程更感兴趣，而不是往回看。[...]
已经创建了一些有关systemd争议的网站和文章：
有很多Hacker News上有趣的讨论的：
在其他发行版中也可以观察到类似的趋势：
暴发户遵循DOTADIW的Unix哲学-“做一件事情，做好事”。它替代了传统的init守护程序。除了启动和停止服务之外，它没有做任何其他事情。其他任务则委托给其他专门的子系统。
systemd的功能远不止于此。除了启动和停止服务外，它还管理密码，登录名，终端，电源管理，工厂重置，日志处理，文件系统挂载点，网络连接以及更多功能-有关某些功能，请参阅NEWS文件。
根据视角的systemd已经取得的成就，以及什么样的未来由伦纳特·珀特林呈现在2014年GNOME.asia，这里有systemd的主要目标，即已经覆盖和那些仍在取得进展的领域：
我们的目标
将Linux从零碎的零碎变成竞争性的通用操作系统。
构建Internet的下一代OS统一发行版之间毫无意义的差异
将创新带回到核心操作系统
桌面，服务器，容器，嵌入式，移动，云，群集等。。。这些区域之间的距离比您想象的要近
降低管理员的复杂性，可靠性而无需监督
一切自省
自动发现，即插即用是关键
我们将东西固定在损坏的地方，永远不要用胶带粘在上面
我们已经介绍的内容：
初始化系统，日志记录，登录管理，设备管理，临时和易失性文件管理，二进制格式注册，背光保存/还原，rfkill保存/还原，引导图，预读，加密存储设置，EFI / GPT分区发现，虚拟机/容器注册，最小容器管理，主机名管理，语言环境管理，时间管理，随机种子管理，sysctl变量管理，控制台管理等。。。
我们正在从事的工作：
- 网络管理
- 系统联网
- 本地DNS缓存，mDNS响应器，LLMNR响应器，DNSSEC验证
- 内核中的IPC
- kdbus，sd-bus
- 与NTP时间同步
- 系统时间同步
- 与容器的更多集成
- 服务沙盒
- 应用程序沙箱
- 操作系统映像格式
- 容器图片格式
- 应用图片格式
- 具有自动发现功能的GPT
- 无状态系统，可实例化系统，出厂重置
- / usr是操作系统
- / etc是（可选）配置
- / var是（可选）状态
- 原子节点初始化和更新
- 与云整合
- 跨节点的服务管理
- 可验证的操作系统映像
- 一直到固件
- 引导加载
正如fpmurphy1在评论中指出的那样，“应该指出，多年来systemd的工作范围已远远超出了系统启动的范围。”
我试图在这里包括大多数相关信息。在这里，我将按照问题中的要求比较Upstart和systemd用作初始化系统时的常见功能，我只提到systemd的功能超出了初始化系统的范围，因为这些功能无法与Startup进行比较，但是它们的存在很重要了解这两个项目之间的区别。有关更多信息，请检查相关文档。
可以在以下位置找到更多信息：
本文收集自互联网，转载请注明来源。
如有侵权，请联系[email protected] 删除。
我来说两句