Hi, I have already mentioned this on IRC, but I'm gonna fill bug on report here as well: This commit: http://cgit.freedesktop.org/systemd/systemd/commit/?id=679142ce4a8def7da43c4d3b2a02bae8c0d21175 sets '/sys/fs/cgroup' as read only to (as commit info suggests) work around bug in glibc. This however prevents userspace programs to create new directories there. For example 'freezer' directory which isn't created by systemd by default at least on my machnie) and in turn, to fail. Aditionally: How to reproduce glibc bug? Was it reported and fixed upstream?
At early boot systemd will mount all controller hierarchies enabled in the kernel into /sys/fs/cgroup/ into individual subdirs. Afterwards it will mount /sys/fs/cgroup/ (but not the hierarchies below) read-only. This means that if you have the "freezer" cgroup hierarchy enabled in the kernel it will find it mounted there anyway. If you do not have it enabled in the kernel you can't mount it anyway. Hence mounting the fs there read-only is the right thing to do.
(oh, and glibc tries to find the right place to place shared memory to, by looking for the first mounted tmpfs. This might end up being /sys/fs/cgroup if /dev/shm happens not to be mounted for some reason. And we don't want that, hence we make it read-only.)
This still seems to be a problem, in that it assume that all cgroups are part of the monolithic file system. Several cgroups (net_cls and net_prio), can be built as modules, and so their presence may not be noted until some arbitrary time after boot. Systemd needs to be able to handle that case. I'd recommend that it not mount the fs heirarchy read-only until after it has interrogated /etc/modules-load.d. That way loading of the requisite modules to register those cgroups can just be mandated prior to read-only mounting.
This is not going to change. If client code wants to mount additional cgroup controllers they can easily turn off the RO bit momentarily.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.