Control groups (cgroups) organize processes into a tree and attach resource controllers (CPU, memory, I/O, process count) to it. Cgroups v1 kept one tree per controller, which made consistent limits hard. Cgroups v2, stable since Linux 4.5, has one unified hierarchy at /sys/fs/cgroup: each directory is a group, its files are the controls, and writing a PID to cgroup.procs moves a process in. Ubuntu 26.04 225 mounts only v2.
stat -fc %T /sys/fs/cgroup
cat /sys/fs/cgroup/cgroup.controllers
cat /proc/"$PID"/cgroup
docker info --format '{{.CgroupDriver}} driver, cgroup v{{.CgroupVersion}}'Output
cgroup2fs cpuset cpu io memory hugetlb pids rdma 0::/system.slice/docker-07915701ea8bf74b6a720fafd082369b9183621cfeef5dff96a01b7f8a53d47d.scope systemd driver, cgroup v2
The single 0:: line is the v2 format, placing l3-ns in a systemd 142,543 scope named after its container ID. With the systemd cgroup driver, Docker 514 asks systemd to create the group, so systemd stays the tree's single owner, the arrangement Kubernetes 5,150 recommends for its nodes.
