☰

使用 systemctl 禁用 snapd

tag-icon • tag-icon 20.10
使用 systemctl 禁用 snapd

snapd 在 Ubuntu 中默认启用，因为执行此操作可以systemctl status snapd快速显示，这当然是意料之中的。因此我尝试了以下操作：

$ sudo systemctl disable --now snapd
$ sudo systemctl disable --now snapd.socket

第一个命令警告snapd.socket可能会重新激活snapd（因此我使用了第二个命令），第二个命令输出符号链接已被删除（正如使用禁用大多数服务/套接字时所预期的那样systemctl）。然后我重新启动以确认更改仍然存在。令我惊讶的是，systemctl status snapd输出以下内容（为方便起见进行了修剪）：

● snapd.service - Snap Daemon
     Loaded: loaded (/lib/systemd/system/snapd.service; disabled; vendor preset: enabled)
     Active: active (running) since Sat 2020-10-31 13:09:38 HKT; 14min ago
TriggeredBy: ● snapd.socket

并systemctl status snapd.socket输出以下内容：

● snapd.socket - Socket activation for snappy daemon
     Loaded: loaded (/lib/systemd/system/snapd.socket; disabled; vendor preset: enabled)
     Active: active (running) since Sat 2020-10-31 13:09:38 HKT; 15min ago
   Triggers: ● snapd.service

上面的输出表明服务和套接字都已按预期禁用；但是，两个状态仍然是active (running)。为什么会这样？Ubuntu 中是否有一些启动脚本可以确保snapd尽管被“禁用”，但仍保持运行？

为了以防万一，这是在 Ubuntu 20.10 上完成的（在新创建的用于测试的 VM 中），尽管我首先注意到在我的其中一台旧机器上安装的裸机 Ubuntu 20.04 LTS 也出现了类似的行为。

PS：其实我不是也它在后台运行让我很困扰snapd，我也不打算删除它，只是想知道为什么 Ubuntu 会出现这种行为（以及是否可以真正禁用它而不完全删除它）。

答案1

正如@N0rbert 在评论中所建议的那样，掩蔽这项服务而不是仅仅禁用它就可以解决问题。

然而，深入挖掘一下，我发现Fedora 杂志上关于 systemd 的一篇文章2015 年底发表的一项研究表明：

回想一下，systemd 可以理解单元之间的依赖关系。这意味着 systemd 可以判断何时必须启动一个单元才能运行另一个单元。

此外，systemd 使用此信息来启动所需的服务，即使残疾，以满足依赖关系。

因此，按照这个提示，我通过执行（对 也类似）列出了snapd.service和的反向依赖关系，以查看哪些单元依赖于。事实证明（已启用）依赖于。一旦我执行snapd.socketsystemctl list-dependencies --reverse snapdsnapd.socketsnapdsnapd.seeded.servicesnapd.socket

$ sudo systemctl disable --now snapd.seeded

并重新启动后，三个设备均恢复inactive (dead)预期。

相关内容