☰

为什么卸载 cgroup v1 后，/sys/fs/cgroup 下仍有空目录？

tag-icon • tag-icon debian mount cgroups tmpfs sysfs
为什么卸载 cgroup v1 后，/sys/fs/cgroup 下仍有空目录？

我刚刚卸载了cgroup版本1cgroup2，在我的系统上只留下一个安装。

$ mount | grep -i cgroup
tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,size=4096k,nr_inodes=1024,mode=755)
cgroup2 on /sys/fs/cgroup/unified type cgroup2 (rw,nosuid,nodev,noexec,relatime,nsdelegate)

我的印象是，其中的所有内容/sys/fs/cgroup都不/sys/fs/cgroup/unified是 cgroup 1 的工件。为什么在卸载cgroup版本 1 后这些仍然存在？

$ ls -lh
drwxr-xr-x  2 root root 40 Dec 25 18:57 blkio
lrwxrwxrwx  1 root root 11 Dec 25 18:57 cpu -> cpu,cpuacct
lrwxrwxrwx  1 root root 11 Dec 25 18:57 cpuacct -> cpu,cpuacct
drwxr-xr-x  2 root root 40 Dec 25 18:57 cpu,cpuacct
drwxr-xr-x  2 root root 40 Dec 25 18:57 cpuset
drwxr-xr-x  2 root root 40 Dec 25 18:57 devices
drwxr-xr-x  2 root root 40 Dec 25 18:57 freezer
drwxr-xr-x  2 root root 40 Dec 25 18:57 memory
lrwxrwxrwx  1 root root 16 Dec 25 18:57 net_cls -> net_cls,net_prio
drwxr-xr-x  2 root root 40 Dec 25 18:57 net_cls,net_prio
lrwxrwxrwx  1 root root 16 Dec 25 18:57 net_prio -> net_cls,net_prio
drwxr-xr-x  2 root root 40 Dec 25 18:57 perf_event
drwxr-xr-x  2 root root 40 Dec 25 18:57 pids
drwxr-xr-x  2 root root 40 Dec 25 18:57 rdma
drwxr-xr-x  2 root root 40 Dec 25 18:57 systemd
dr-xr-xr-x 13 root root  0 Dec 26 21:37 unified

这些剩余的临时目录不是内核接口吗？

$ find . | grep -v unified
./freezer
./cpuset
./cpu
./cpuacct
./cpu,cpuacct
./rdma
./perf_event
./blkio
./memory
./devices
./net_prio
./net_cls
./net_cls,net_prio
./pids
./systemd

这些空目录如何与cgroupsv1 一起使用？

答案1

这是因为您处于 systemd 的“混合”模式，该模式使用 cgroup v2 进行其自己的内部簿记，但仍然使用 cgroup v1 进行资源控制。来自cgroup 委托文档:

systemd 支持三种不同的 cgroup 设置模式。具体来说：

  1. 统一— 这是最简单的模式，并公开纯粹的 cgroup v2 逻辑。在此模式下，/sys/fs/cgroup是唯一安装的 cgroup API 文件系统，所有可用的控制器都通过它独占公开。

  2. 遗产— 这是传统的 cgroup v1 模式。在此模式下，各个控制器都会将自己的 cgroup 文件系统挂载到 /sys/fs/cgroup/<controller>/.除此之外，systemd 还管理自己的 cgroup 层次结构，以实现/sys/fs/cgroup/systemd/.

  3. 杂交种——这是统一模式和遗留模式的混合体。它的设置与旧版本基本相似，只是还有一个 /sys/fs/cgroup/unified/包含 cgroup v2 层次结构的附加层次结构。 （请注意，在此模式下，统一层次结构不会附加控制器，控制器都作为单独的层次结构安装，就像传统模式一样，即/sys/fs/cgroup/unified/纯粹且排他地涉及核心 cgroup v2 功能，而不是资源管理。）在此模式下兼容性保留了 cgroup v1，同时也提供了一些 cgroup v2 功能。这种模式只是权宜之计。除非你有太多空闲时间，否则不要太在意这个。

明确地说，传统模式和混合模式没有未来。如果您今天开发软件并且不关注统一模式，那么您正在为昨天而不是明天编写软件。对它们的支持主要是出于兼容性原因，并且不会获得新功能。

简单地删除资源目录将使 systemd 无法执行大多数资源控制指令，因为它不再有权访问执行此操作所需的目录层次结构。

systemd.unified_cgroup_hierarchy=1 cgroup_no_v1=all相反，要使用“统一”模式启动 systemd，该模式使用 cgroup v2 进行其自己的内部簿记和资源控制，您可以在内核命令行上启动系统（或者仅cgroup_no_v1=all在 v240+ 中，请参阅这个补丁）。

cgroup_no_v1=all告诉内核禁用所有旧的 cgroup 层次结构，这确保没有人可以抓住它们并将它们作为人质，并systemd.unified_group_hierarchy=1告诉 systemd 使用统一的 cgroup 层次结构，而不是发行版默认配置的混合层次结构。

一旦你启动了它，你会发现所有内容都位于 /sys/fs/cgroup 下面，如你所愿：

% ls -l /sys/fs/cgroup | head
total 0
drwxr-xr-x  2 root root 0 Feb 17 17:19 dev-hugepages.mount/
drwxr-xr-x  2 root root 0 Feb 17 17:19 dev-mqueue.mount/
drwxr-xr-x  2 root root 0 Feb 17 17:19 init.scope/
drwxr-xr-x  2 root root 0 Feb 17 17:19 sys-fs-fuse-connections.mount/
drwxr-xr-x  2 root root 0 Feb 17 17:19 sys-kernel-config.mount/
drwxr-xr-x  2 root root 0 Feb 17 17:19 sys-kernel-debug.mount/
drwxr-xr-x  2 root root 0 Feb 17 17:19 sys-kernel-tracing.mount/
drwxr-xr-x 21 root root 0 Feb 21 13:00 system.slice/
drwxr-xr-x  4 root root 0 Feb 17 17:19 user.slice/

答案2

其实很简单。所有cgroup安装都必须在目录顶部完成。在你拥有之前，

cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,xattr,name=systemd)
cgroup on /sys/fs/cgroup/pids type cgroup (rw,nosuid,nodev,noexec,relatime,pids)
cgroup on /sys/fs/cgroup/net_cls,net_prio type cgroup (rw,nosuid,nodev,noexec,relatime,net_cls,net_prio)
cgroup on /sys/fs/cgroup/devices type cgroup (rw,nosuid,nodev,noexec,relatime,devices)
cgroup on /sys/fs/cgroup/memory type cgroup (rw,nosuid,nodev,noexec,relatime,memory)
cgroup on /sys/fs/cgroup/blkio type cgroup (rw,nosuid,nodev,noexec,relatime,blkio)
cgroup on /sys/fs/cgroup/perf_event type cgroup (rw,nosuid,nodev,noexec,relatime,perf_event)
cgroup on /sys/fs/cgroup/rdma type cgroup (rw,nosuid,nodev,noexec,relatime,rdma)
cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,cpu,cpuacct)
cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,nosuid,nodev,noexec,relatime,cpuset)
cgroup on /sys/fs/cgroup/freezer type cgroup (rw,nosuid,nodev,noexec,relatime,freezer)

当你卸载了所有这些，您将底层目录留在那里。唉，这些可以通过重新安装/sys/fs/cgroup并rw简单地删除它们来删除。

sudo mount -o remount,rw /sys/fs/cgroup
# Delete the symlinks
sudo find /sys/fs/cgroup -maxdepth 1 -type l -exec rm {} \;
# Delete the empty directories
sudo find /sys/fs/cgroup/ -links 2 -type d -not -path '/sys/fs/cgroup/unified/*' -exec rmdir -v {} \;
sudo mount -o remount,ro /sys/fs/cgroup

之后你就应该看到你cgroup2剩下的美丽和干净，

$ ls /sys/fs/cgroup
unified

答案3

也许可以节省您到处检查的时间，这是在 Ubuntu 20.04 上执行此操作的方法。

  1. 验证 systemd 版本：systemd --version这应该输出版本 240+，因此我们可以根据以下内容使用短版本这个帖子
  2. 在以以下内容开头的最后一行之后添加此内容GRUB_CMDLINE_LINUX

GRUB_CMDLINE_LINUX="${GRUB_CMDLINE_LINUX} cgroup_no_v1=all" 这实际上将附加cgroup_no_v1=all到启动参数中。

  1. 保存文件并执行sudo update-grub
  2. 重新启动机器。
  3. cat /proc/cmdline重启后进行验证。如果您 cgroup_no_v1=all在输出中看到，则表示 cgroup v2 处于活动状态。

相关内容