Hi,
With systemd 232, they now mount /sys/fs/cgroup/systemd with cgroup2 aka unified hierarchy https://github.com/systemd/systemd/pull/3965
This breaks runc with the error: no subsystem for mount
I had to use the systemd.legacy_systemd_cgroup_controller=yes boot parameter to fix it.
... scream internally
While this _should_ be okay to handle, I really wish they hadn't implemented that. The cgroup migration code (having processes in some cgroupv2 controllers but not others) is not very safe IMO. Not to mention that the incompatibilities will make this an enormous pain to deal with.
Just want to confirm that the workaround to use systemd.legacy_systemd_cgroup_controller=yes as a boot parameter (adding it to /etc/default/grub @ GRUB_CMDLINE_LINUX_DEFAULT and running update-grub && reboot) "fixed" it for me.
It looks like systemd/systemd#4628 is going to revert the regression. From the discussion linked, it looks like the solution is for us to mount a fake v1 name=systemd hierarchy and then just use that as the bindmount. Now, this isn't pretty by any stretch of the imagination (and I have my doubts about the overall stability of systemd's truly insane cgroup handling) but we don't really have a choice right now.
https://github.com/systemd/systemd/pull/4628 reverted this for now, but you can still boot with systemd.legacy_systemd_cgroup_controller=0 to get the unified behaviour; that is useful for developers to make runc/docker/lxc/etc. work with the unified hierarchy eventually.
I can confirm that this is still an issue as of systemd-233, and the above workaround still works.
The latest version of runC includes #1266 which should fix this problem in the hybrid mode that systemd 232 shipped. AFAIK the newest Docker release should contain that fix.
I know this is an old thread, but just to make it pop up in google serches a bit more, upon upgrading my Ubuntu Server 17.04->10 I ran head long into this issue as well (17.10 uses systemd 2.34 if it's any help). I'm about to try the later fix of changing the cgroup driver, before I use the initial work-around of change the kernel boot up parameters which could break other things that expect the new cgroup implementation on 17.10.
@ajw107 runc does have a fix for this bug (#1266). Most distributions should've backported that fix (we did that in SLE and openSUSE for example).
@ajw107 did you manage to fix that issue? I have the same problem and frankly not really a clue what I can do to solve this. Also thanks @cyphar I see the fix but no idea what to do with it.
Most helpful comment
... scream internally
While this _should_ be okay to handle, I really wish they hadn't implemented that. The cgroup migration code (having processes in some
cgroupv2controllers but not others) is not very safe IMO. Not to mention that the incompatibilities will make this an enormous pain to deal with.