使用 systemctl 禁用 snapd

Question

snapd 在 Ubuntu 中默认启用，因为它可以systemctl status snapd快速显示，这当然是预期的。所以我尝试了以下方法：

\n

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

\n

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

\n

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

\n

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

\n

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

\n

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

\n

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

\n

PS 实际上，我并不太在意在snapd后台运行，也不是为了删除它，而是想知道为什么 Ubuntu 会表现出这种行为（以及在不完全删除它的情况下真正禁用它是否可行）。

\n

Answer 1

正如 @N0rbert 在评论中建议的那样，屏蔽该服务而不是仅仅禁用它应该可以解决问题。

然而，深入研究后，我发现Fedora 杂志于 2015 年底发表了一篇关于 systemd 的文章，其中指出：

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

此外，systemd 使用此信息来启动所需的服务（即使已禁用）以满足依赖性。

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

$ sudo systemctl disable --now snapd.seeded

重新启动后，所有三个单元均inactive (dead)符合预期。