54

I want to try cgroup v2 but am not sure if it is installed on my linux machine

>> uname -r 4.14.66-041466-generic

Since cgroup v2 is available in 4.12.0-rc5, I assume it should be available in the kernel version I am using.

https://www.infradead.org/~mchehab/kernel_docs/unsorted/cgroup-v2.html

However, it does not seem like my system has cgroup v2 as the memory interface files mentioned in its documentation are not available on my system.

https://www.kernel.org/doc/Documentation/cgroup-v2.txt

It seems like I still have cgroup v1.

/sys/fs/cgroup/memory# ls cgroup.clone_children memory.kmem.failcnt memory.kmem.tcp.usage_in_bytes memory.memsw.usage_in_bytes memory.swappiness cgroup.event_control memory.kmem.limit_in_bytes memory.kmem.usage_in_bytes memory.move_charge_at_immigrate memory.usage_in_bytes cgroup.procs memory.kmem.max_usage_in_bytes memory.limit_in_bytes memory.numa_stat memory.use_hierarchy cgroup.sane_behavior memory.kmem.slabinfo memory.max_usage_in_bytes memory.oom_control notify_on_release docker memory.kmem.tcp.failcnt memory.memsw.failcnt memory.pressure_level release_agent memory.failcnt memory.kmem.tcp.limit_in_bytes memory.memsw.limit_in_bytes memory.soft_limit_in_bytes tasks memory.force_empty memory.kmem.tcp.max_usage_in_bytes memory.memsw.max_usage_in_bytes memory.stat

Follow-up questions Thanks Brian for the help. Please let me know if I should be creating a new question but I think it might be helpful to other if I just ask my questions here.

1) I am unable to add cgroup controllers, following the command in the doc

>> echo "+cpu +memory -io" > cgroup.subtree_control

However, I got "echo: write error: Invalid argument". Am I missing a prerequisite to this step?

2) I ran a docker container but the docker daemon log complained about not able to find "/sys/fs/cgroup/cpuset/docker/cpuset.cpus". It seems like docker is still expecting cgroupv1. What is the best way to enable cgroupv2 support on my docker daemon?

docker -v Docker version 17.09.1-ce, build aedabb7
Improve this question

6 Answers 6

Reset to default
77

You could run the following command:

grep cgroup /proc/filesystems

If your system supports cgroupv2, you would see: 

nodev cgroup nodev cgroup2

On a system with only cgroupv1, you would only see: 

nodev cgroup
Improve this answer
1
  • 1
    If you'd like a bit of informaiton, try: mount -t cgroup2 ==> cgroup2 on /sys/fs/cgroup/unified type cgroup2 (rw,nosuid,nodev,noexec,relatime,nsdelegate). If you look for a nonexistant group type, nothing happens. Commented Aug 11, 2020 at 1:58
17

It might be not relevant not only to see if cgroups v2 are supported, but also whether they are enabled and for that following command can be used:

stat -fc %T /sys/fs/cgroup/

In case the output states cgroup2fs then cgroups v2 are used, tmpfs in case cgroups v1. In case system supports cgroups v2, but not activated by default then it could be enabled by setting systemd.unified_cgroup_hierarchy=1 as kernel parameter (eg. GRUB_CMDLINE_LINUX="systemd.unified_cgroup_hierarchy=1" in systems with GRUB)

Improve this answer
2
16

The easiest way is to attempt to mount the pseudo-filesystem. If you can mount it to a location, then you can attempt to manage processes with the interface:

mount -t cgroup2 none $MOUNT_POINT

I see that you cited the documentation above. One of the points you may be missing is that the paths still need to be created. There's no reason you must manage cgroup resources at any particular location. It's just convention.

For example, you could totally present procfs at /usr/monkeys... as long as the directory /usr/monkeys exists:

$ sudo mkdir /usr/monkeys $ sudo mount -t proc none /usr/monkeys $ ls -l /usr/monkeys ... ... -r--r--r--. 1 root root 0 Sep 25 19:00 uptime -r--r--r--. 1 root root 0 Sep 25 23:17 version -r--------. 1 root root 0 Sep 25 23:17 vmallocinfo -r--r--r--. 1 root root 0 Sep 25 18:57 vmstat -r--r--r--. 1 root root 0 Sep 25 23:17 zoneinfo $ sudo umount /usr/monkeys

In the same way I can do this with the cgroup v2 pseudo-filesystem:

$ sudo mount -t cgroup2 none /usr/monkeys $ ls -l /usr/monkeys total 0 -r--r--r--. 1 root root 0 Sep 23 16:58 cgroup.controllers -rw-r--r--. 1 root root 0 Sep 23 16:58 cgroup.max.depth -rw-r--r--. 1 root root 0 Sep 23 16:58 cgroup.max.descendants -rw-r--r--. 1 root root 0 Sep 23 16:58 cgroup.procs -r--r--r--. 1 root root 0 Sep 23 16:58 cgroup.stat -rw-r--r--. 1 root root 0 Sep 23 16:58 cgroup.subtree_control -rw-r--r--. 1 root root 0 Sep 23 16:58 cgroup.threads drwxr-xr-x. 2 root root 0 Sep 23 16:58 init.scope drwxr-xr-x. 2 root root 0 Sep 23 16:58 machine.slice drwxr-xr-x. 59 root root 0 Sep 23 16:58 system.slice drwxr-xr-x. 4 root root 0 Sep 23 16:58 user.slice $ sudo umount /usr/monkeys
Improve this answer
3
  • Hi Brian, thanks for the help. Wondering if you could help me with my two follow up questions. Feel free to let me know if I should be creating a new question instead. Commented Sep 26, 2018 at 13:43
  • @user3397467 You would be better off creating a separate question of the form "How do I configure Docker to use cgroupsv2?", calling out your how you're installing docker (via a distro shipped package, docker CE from their repos, etc), the distro you are running, and any configurations you may have set up to that point. Commented Sep 26, 2018 at 16:10
  • when I do this I get a weird error. root@ip-10-0-1-179:/home/ubuntu# echo "+io" > /cgroup2/cgroup.subtree_control bash: echo: write error: No such file or directory root@ip-10-0-1-179:/home/ubuntu# ls -la /cgroup2/ total 0 drwxr-xr-x 6 root root 0 Feb 5 18:13 . drwxr-xr-x 6 root root 0 Feb 5 18:13 .. drwxr-xr-x 2 root root 0 Feb 5 18:13 cg1 ... -rw-r--r-- 1 root root 0 Feb 5 18:13 cgroup.subtree_control drwxr-xr-x 2 root root 0 Feb 5 18:03 init.scope drwxr-xr-x 59 root root 0 Feb 5 17:47 system.slice drwxr-xr-x 3 root root 0 Feb 5 17:57 user.slice Commented Feb 5, 2020 at 18:16
10

To check if your Linux system supports cgroup v2 check for the existence of cgroup.controllers:

$ cat /sys/fs/cgroup/cgroup.controllers cpuset cpu io memory hugetlb pids rdma

To boot the host with cgroup v2, add the following string to the GRUB_CMDLINE_LINUX line in /etc/default/grub and then run sudo update-grub:

  • systemd.unified_cgroup_hierarchy=1

Also helpful - checking if you are in an unprivileged namespace

Improve this answer
1
  • 1
    This is Docker's recommended check. First link also contains useful info on enabling cfgroup v2. Might be good to include that here, as that was would I personally was after. Commented Sep 13, 2021 at 8:24
3

Some systems will mount cgroup v1 and cgroup v2 by default, just in different locations. It can help to see where those are with:

grep ^cgroup /etc/mtab

Example output (on Ubuntu 20.04 LTS):

cgroup2 /sys/fs/cgroup/unified cgroup2 rw,nosuid,nodev,noexec,relatime 0 0 cgroup /sys/fs/cgroup/systemd cgroup rw,nosuid,nodev,noexec,relatime,xattr,name=systemd 0 0 cgroup /sys/fs/cgroup/cpu,cpuacct cgroup rw,nosuid,nodev,noexec,relatime,cpu,cpuacct 0 0 cgroup /sys/fs/cgroup/devices cgroup rw,nosuid,nodev,noexec,relatime,devices 0 0 cgroup /sys/fs/cgroup/memory cgroup rw,nosuid,nodev,noexec,relatime,memory 0 0 cgroup /sys/fs/cgroup/freezer cgroup rw,nosuid,nodev,noexec,relatime,freezer 0 0 cgroup /sys/fs/cgroup/rdma cgroup rw,nosuid,nodev,noexec,relatime,rdma 0 0 cgroup /sys/fs/cgroup/cpuset cgroup rw,nosuid,nodev,noexec,relatime,cpuset 0 0 cgroup /sys/fs/cgroup/blkio cgroup rw,nosuid,nodev,noexec,relatime,blkio 0 0 cgroup /sys/fs/cgroup/net_cls,net_prio cgroup rw,nosuid,nodev,noexec,relatime,net_cls,net_prio 0 0 cgroup /sys/fs/cgroup/pids cgroup rw,nosuid,nodev,noexec,relatime,pids 0 0 cgroup /sys/fs/cgroup/hugetlb cgroup rw,nosuid,nodev,noexec,relatime,hugetlb 0 0 cgroup /sys/fs/cgroup/perf_event cgroup rw,nosuid,nodev,noexec,relatime,perf_event 0 0

However, this does not strictly tell you if your system supports cgroup v2. As the other answer mentioned, grep cgroup /proc/filesystems is great for that.

Improve this answer
1

The most straightforward answer today may be provided by podman:

podman info --format {{.Host.CgroupsVersion}}

This will display either v1 or v2.

Name and position of the key has changed over the years, so if you get a template error, you can try this instead:

podman info |grep -i cgroup

Podman has added cgroups v2 support in 2019, with version 1.6.0. So this won't work on very old systems that has older podman available.

Of course one caveat is that you need podman installed. Most distributions should have it in the repos.

Improve this answer

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.