1

As the title of my question suggests, I am trying to edit the properties of my cgroup virtual file system - create new directories, edit the resource limits in certain files, etc - but any write action I take returns:

cannot do action in 'fs/cgroup/': Read-only file system

Even after running chmod 755 as root, the result is the same. Confirming root has write access, I check the output of ls -al and see:

drwx-xr-x 15 root root 380 Mar 31 09:28 cgroup

When I read online examples, editing/creating files within /cgroup/ is an initial step covered, with no mention of issues performing this task. Seeking a solution, I thought possibly the issue is because the cgroup is mounted. That, because all system processes are listed within it, I am not allowed to edit its contents.

Following this hunch, I attempted to unmount the cgroup:

umount cgroup

Which returned the usual:

target is busy.

To my knowledge, a root user attempting to write to a directory owned by root, with root write permissions, should be allowed - what am I not seeing ?

I have been reading various man pages, the online kernel site, and several helpful stack excahnge posts such as How to use cgroups to limit all processes except whitelist to a single CPU?. Nowhere am I able to find reference to the issue I am encountering.

Does anyone with more experience have a light they could shine in my direction ?

Update

The cgroups listed at mounted, shown by running grep cgroup /proc/mounts, are:

tmpfs /sys/fs/cgroup tmpfs ro,nosuid,nodev,noexec,mode=755 0 0
cgroup2 /sys/fs/cgroup/unified cgroup2 rw,nosuid,nodev,noexec,relatime,nsdelegate 0 0
cgroup /sys/fs/cgroup/systemd cgroup rw,nosuid,nodev,noexec,relatime,xattr,name=systemd 0 0
cgroup /sys/fs/cgroup/devices cgroup rw,nosuid,nodev,noexec,relatime,devices 0 0
cgroup /sys/fs/cgroup/cpuset cgroup rw,nosuid,nodev,noexec,relatime,cpuset 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/rdma cgroup rw,nosuid,nodev,noexec,relatime,rdma 0 0
cgroup /sys/fs/cgroup/perf_event cgroup rw,nosuid,nodev,noexec,relatime,perf_event 0 0
cgroup /sys/fs/cgroup/cpu,cpuacct cgroup rw,nosuid,nodev,noexec,relatime,cpu,cpuacct 0 0
cgroup /sys/fs/cgroup/freezer cgroup rw,nosuid,nodev,noexec,relatime,freezer 0 0
cgroup /sys/fs/cgroup/memory cgroup rw,nosuid,nodev,noexec,relatime,memory 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/blkio cgroup rw,nosuid,nodev,noexec,relatime,blkio 0 0

Specific Command Outputs

Specific commands I have tried to write with, and their outputs, are:

  1. In /sys/fs/cgroup/unified, with ls showing the file cgroup.subtree_control exists:
echo "+cpu +memory" > cgroup.subtree_control
bash: echo: write error: No such file or directory
  1. Attempting to write desired controllers direct to cgroup.controllers gives:
echo "cpu" > cgroup.controllers
bash: echo: write error: Invalid argument
  1. If I try to write to the file cgroup.subtree_control via nano, the nano client opens the file but displays at the screen bottom:
[ Error writing lock file ./.cgroup.subtree_control.swp: Permission denied ]
  1. Creating a file on /sys/fs/cgroup/unified is denied:
touch file
touch: cannot touch 'file': Permission denied
  1. Creating a directory on /sys/fs/cgroup/unified is allowed:
mkdir newDir

And is populated with cgroup files:

ls newDir
cgroup.controllers  cgroup.max.descendants  cgroup.threads  io.pressure
cgroup.events       cgroup.procs            cgroup.type     memory.pressure
cgroup.freeze       cgroup.stat             cpu.pressure
cgroup.max.depth    cgroup.subtree_control  cpu.stat

But I once again cannot create (via touch) or edit:

echo cpu > cgroup.controllers
bash: echo: write error: Invalid argument
  1. I expected the root cgroup.controller file to contain some controllers, however this is not the case:
cat cgroup.controllers
# returns an empty string

Perhaps this is a hint toward the issue ?

My expectations as the output of these commands are based on the kernel documentation here: https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v2.html

Update 2

After unmounting cgroup version 1 filesystems with:

mount -t cgroup | cut -f 3 -d ' ' | xargs sudo umount

The root unified directory file named cgroup.controllers now does contain controller names:

cat cgroup.controllers
cpuset cpu io rdma

And I may write these names to the cgroup.subtree_controller:

echo -n "+cpuset +cpu +io +rdma " >> cgroup.subtree_controller

But attempting to write a new controller, for example the memory controller, won't work:

echo -n "+memory " > cgroup.subtree_controller
bash: echo: write error: No such file or directory

System Specs

-OS: Ubuntu 20.04.6 LTS

-Kernel: Linux 5.4.0-174-generic

1
  • Add to your answer: What is the output of grep cgroup /proc/mounts and exactly what file did you try to modify that it gave you Read-only file system
    – user10489
    Commented Mar 31 at 20:53

1 Answer 1

1

The problem is caused by the kernel using both cgroup versions 1 and 2.

It is possible to enable both cgroup versions 1 and 2, which was the case for my issue. This was a problem as if a resource controller is attached to a cgroup version 1 filesystem, it may not be attached to a cgroup version 2 filesystem.

A possible solution for this, is to unmount the cgroup version 1 filesystems, detach their controllers, and reattach the controllers to the cgroup version 2 filesystem (mounted under /sys/fs/cgroup/unified/ by default). This would need to be done on each boot.

Alternatively, I have prevented cgroup version 1 from being loaded at boot time. I achieved this by adding the line:

GRUB_CMDLINE_LINUX="systemd.unified_cgroup_hierarchy=1 cgroup_no_v1=all"

to my /etc/default/grub file. To activate these file changes, I then run:

update-grub

The result: the cgroup version 2 file system is mounted directly under /sys/fs/cgroup. There is no unified subdirectory - the absolute path sys/fs/cgroup is the version 2 mount point.

1
  • Good detective work!
    – shellter
    Commented Apr 2 at 17:12

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .