在什么时候为 systemd 初始化 cgroup？

Question

因此，长话短说，我试图让 systemd 与 Arch 安装一起工作，但没有从 init 运行 systemd。这意味着我正在启动一个没有运行 systemd 的系统，然后尝试在其上启动 systemd。

我面临的问题与 cgroups 有关 - 在启动期间，systemd 抱怨缺少 /sys/fs/cgroup/systemd 作为 cgroup，因此运行时功能减少，因为它认为 cgroups 不可用。这会导致任何使用 D-Bus 与 systemd 通信的工具出现问题。

正常运行 systemd（作为 PID 1 运行）cgroups 被正确创建并且 systemd 可以完全工作。但是，当它在已经启动的系统上运行时，不会创建 cgroup。我想知道在 init 过程中的哪个点是 /sys/fs/cgroup/systemd 创建/挂载，以及如何在已经运行的系统上复制它？我可以确认不是 /sbin/init 创建了 cgroup，因为运行它会产生相同的结果。

否则，我应该从哪里开始查看 systemd 的源代码？或者也许有一个邮件列表，我可以直接从开发人员那里得到更好的答案？

Answer 1

是的，所以在对 的源代码进行了一番挖掘之后systemd，我找到了 systemd cgroup 的创建点。在src/core/main.c内main()的函数mount_setup_early()被调用，但只有当systemd正在作为PID 1且不在容器中。mount_setup_early()在 中定义src/core/mount-setup.c，并且只是挂载某些基本文件系统，例如/proc，/dev更重要的是/sys/fs/cgroup/systemd.

我试图以systemdPID != 1运行的事实意味着这个函数从未被执行过。因此，进一步向下main() test_cgroups()执行，并且由于/sys/fs/cgroup/systemd未安装而失败。由于没有办法欺骗这个进程的 PID（或者至少，不是我知道或愿意尝试的），因此解决方案是在执行systemd. 至少，这是理论。

这次冒险的另一个有趣的副作用是对命名层次结构如何与 cgroups 一起工作有了更多的了解。几乎没有可用于 cgroup 的文档，尤其是关于命名层次结构的工作原理。要以与安装方式类似的方式挂载命名层次结构systemd，请运行：

mount -t cgroup cgroup -o none,name=<name> <mountpoint>

这为您提供了一个完全空白的层次结构，类似于name=systemd安装在 上的层次结构/sys/fs/cgroup/systemd。如果要将子系统绑定到该层次结构，请替换none为所需的子系统。