长话短说，我尝试让 systemd 与 Arch 安装配合使用，但不从 init 运行 systemd。这意味着我启动到未运行 systemd 的系统，然后尝试在其上启动 systemd。
我面临的问题与 cgroups 有关 - 在启动期间，systemd 抱怨缺少 /sys/fs/cgroup/systemd 作为 cgroup，因此运行时功能减少，因为它认为 cgroups 不可用。这会导致使用 D-Bus 与 systemd 通信的任何工具出现问题。
正常运行 systemd（以 PID 1 运行）时，cgroup 已正确创建，systemd 可完全正常工作。但是，当它在已启动的系统上运行时，不会创建任何 cgroup。我想知道在 init 进程的哪个阶段创建/挂载 /sys/fs/cgroup/systemd，以及如何在已运行的系统上复制它？我可以确认不是 /sbin/init 创建了 cgroup，因为运行它会产生相同的结果。
如果失败了，我应该从哪里开始查找 systemd 的源代码？或者也许有一个邮件列表，我可以直接从开发人员那里获得更好的答案？
答案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。
我尝试systemd以 PID != 1 运行，这意味着该函数从未执行过。因此，进一步执行main() test_cgroups()，由于未安装而失败/sys/fs/cgroup/systemd。由于没有办法欺骗此进程的 PID（或者至少，我不知道或愿意尝试），解决方案是在执行之前手动安装这些文件系统systemd。至少，这是理论上的。
这次冒险的另一个有趣的副作用是，我们对命名层次结构如何与 cgroup 配合使用有了更多的了解。关于 cgroup 的文档很少，尤其是关于命名层次结构究竟如何工作的文档。要以类似于它的方式挂载命名层次结构systemd，请运行：
mount -t cgroup cgroup -o none,name=<name> <mountpoint>
这将为您提供一个完全空白的层次结构，类似于name=systemd安装在 上的层次结构/sys/fs/cgroup/systemd。如果您想将子系统绑定到该层次结构，请将其替换none为所需的子系统。
答案2
systemd 是一个 init 系统，即使你设法让它运行PID != 1，也肯定会有许多出现问题（例如哪个 init 进程将负责启动/停止进程？）
如果您需要的话，有cgroups不使用 的使用方法systemd，因为它们是在内核中实现的，而不是在 中实现的systemd，后者“仅”使用这些功能。
根据开发者提供的信息，systemd网页上列出了各类资源，包括几个邮件列表，git仓库的URL以及项目文档，非常全面。