Nik*_*dis 28 upstart systemd 15.04
Ubuntu 15.04 带来的更大变化是从 upstart 切换到 systemd 作为管理引导和系统服务启动的默认设置。
任何人都可以向非技术用户充分解释这如何以及是否会影响我们？为什么它很重要？
Oli*_*Oli 30
按照设计，外行用户不应注意到任何变化。这是一个初始化系统，而不是用户传统上与之交互的东西。它应该完全取代 Upstart 提供的功能 - 并做一些额外的事情 - 但非技术用户唯一会看到它的时候是它出错的时候。
一直在为 Upstart 积极使用和开发的用户、系统管理员和开发人员是需要解决问题的人。Ubuntu Wiki 上有一个迁移文档可以帮助开发人员转换他们的 init 脚本，但是用户和系统管理员可以通过坚持使用 14.04（支持到 2019 年）来继续使用 Upstart。
改变的原因和理由真的不是来自 Ubuntu 方面。Canonical 对 Upstart（他们的项目）很满意，但许多 Debian 用户希望转向现代 init 引擎，以在启动时获得更好的并发性，并在所有服务中获得更好的监控功能。
这意味着各种选项（基本原理）之间的斗争最终赢得了 systemd。
Canonical 与 Debian 一起使用，因为它最简单，也可能是最好的。他们可以放弃一个项目，而不是逆流而上。它还使我们与其他也在转向 systemd 的发行版（Red Hat、Fedora 等）保持一致。更加专注，减少重复工作。
tl;dr对于非技术人员，这根本不会影响您。对于 Ubuntu，它应该意味着更少的工作和更好的初始化系统。
Jde*_*eBP 18
任何人都可以向非技术用户充分解释这如何以及是否会影响我们？
从理论上讲，这不应该影响不参与系统实际工作原理的非技术最终用户。在实践中，你会看到很多东西。
这是一个不完整的列表：
init+ 的其他 Linux 操作系统用户rc被 systemd仅向后兼容 System 5的事实所困扰rc。像 upstart 和大多数其他系统一样，它声称并提供与 System 5init及其配置文件不向后兼容/etc/inittab。因此，那些遵循 30 多年“嗯，你可以将其编辑成/etc/inittab……”的人的建议，或者使用遵循该建议的软件的人现在拥有的软件不是从引导程序开始的。示例：https : //unix.stackexchange.com/a/196197/5132
shutdown，就像使用以前的shutdown命令一样。除了在 systemd 术语中称为救援模式这一事实之外，救援模式在 systemd 世界观中不被视为关闭状态。它被视为一种运行状态。 shutdown now将关闭机器电源。它是systemctl rescue在 systemd 世界中达到单用户模式。进一步阅读：https : //unix.stackexchange.com/a/196471/5132--user选项的命令systemctl。这不适用于 Ubuntu（目前）。upstart 和 systemd 在这方面有很大的不同，Ubuntu 15 版仍然使用 upstart per-session init而不是 systemd per-user instance。因此，例如https://superuser.com/a/860598/38062将不适用。☺正如其他人在这里已经指出的那样，理论上，这不应该影响非技术最终用户——理论上，理论和实践之间没有区别，但在实践中是有区别的。
我认为这里发布的内容很少需要澄清：
这是一个初始化系统，而不是用户传统上与之交互的东西。
SysV init 和 Upstart 都是这种情况，但 systemd 不再是这种情况。它做了很多用户传统上与之交互的事情：
它应该完全取代 Upstart 提供的功能——并做一些额外的事情
有两件事需要澄清 - 首先是完全取代 Upstart：
人们对 systemd 的问题之一是它不运行 SysV init 脚本。所以有一个例子，它并没有完全取代 Upstart 提供的功能。
这是我们可以依赖 30 多年的东西，传统上您编写 SysV init 脚本以获得最大的可移植性，而无需重复自己（通过编写相同脚本的多个版本），现在已不再如此。
当仅使用来自官方存储库的包时，这应该不是问题，因为大概所有曾经具有 SysV init 或 Upstart 脚本的包都需要在打包之前重写它们的脚本。
对于碰巧使用为 SysV init 或 Upstart 编写 init 脚本的任何第三方或自定义软件的人来说，这只是一个问题，并且在升级到具有 systemd 的系统之前需要重写 init 脚本（或获取安装新贵，这也是一个选项，或迁移到不使用 systemd 的系统）。
有 systemd-sysv-generator 应该自动将 SysV init 脚本转换为 systemd 脚本，但存在一些错误和一长串明确的不兼容性。
现在，第二个澄清 - 关于那些额外的事情：
根据A Perspective for systemd - What Has Being Achieved，以及Lennart Poettering于 2014 年在 GNOME.asia上发表的演讲，systemd 将涵盖的“一些额外的东西”如下：
所以回到：“这是一个初始化系统，而不是用户传统上与之交互的东西。” - 必须指出，init 系统只是该列表中的一项。
最后，我想评论的最后一件事：
[T]他只有在出现问题时非技术用户才会看到这一点。
哦，真是一种解脱。:)
对于最终用户（脚本本身除外）最显着的变化是启动和停止服务以及使用如下命令：
不再按预期工作。例如，nohup是一个 POSIX 命令，用于确保在您从会话注销后该进程继续运行。它不再适用于 systemd。像这样的程序screen也tmux需要以特殊方式调用，否则与它们一起运行的进程将被杀死（而没有杀死这些进程通常是首先运行 screen 或 tmux 的主要原因）。
这不是错误，而是设计选择，因此将来不太可能修复。这就是 Lennart Poettering对这个问题所说的：
在我看来，UNIX 在默认情况下让任意用户代码在注销后不受限制地保留实际上很奇怪。许多 OS 人员已经讨论了很长时间，这应该是可能的，但肯定不是默认设置，但到目前为止没有人敢打开开关将其从默认设置变为选项。注销后不清理用户会话不仅丑陋且有些骇人听闻，而且还是一个安全问题。 systemd 230 现在终于打开了开关，默认情况下，当用户注销时，最后会正确清理所有内容。
有关更多信息，请参阅：
screenscreensystemd-run --user --scope screen（注意：上面“暴发户”的行为实际上是除了 systemd 之外的任何东西，这不是暴发户特定的）
start foosystemctl start foostop foosystemctl stop foorestart foosystemctl restart fooinitctl listsystemctl status（有关超出此问题范围的更多详细信息，请参阅我对 Upstart 和 systemd 的优缺点是什么的回答。）
处理日志也有很大的不同，因为与 Unix 传统相反，systemd 的日志以自定义格式存储在二进制文件中，因此：
cat /var/log/upstart/foo.log
tail -f /var/log/upstart/foo.log
您需要使用特殊命令来访问您的日志：
sudo journalctl -u foo
sudo journalctl -u foo -f
将 systemd 首先引入 Debian，然后引入 Ubuntu 并非没有争议和巨大的反对，正如撰写以下文章之一的任何人所知：
Debian 对 systemd的官方立场以及由此产生的争议导致了2014 年的Exodus 宣言，并以Ian Jackson 的辞职告终。
Init Freedom、 Without-Systemd.org和Systemd-Free.org倡议诞生了，在 Hacker News 上进行了大量讨论。
| 归档时间： |
|
| 查看次数： |
13129 次 |
| 最近记录： |