the sysfs init script, by default, mounts each cgroup-subsystem into /sys/fs/cgroup/$subsystem. This behaviour can be turned off by setting rc_cgroups="NO" in /etc/rc.conf When processing /etc/init.d/sysfs, mount_cgroups() then does no longer mount the individual subsystems, but at the end of mount_misc() the tmpfs to mount the subsystems into will still be created. Reproducible: Always Steps to Reproduce: 1. set rc_cgroups="NO" in /etc/rc.conf 2. reboot Actual Results: /sys/fs/cgroup/ is a 10M tmpfs Expected Results: no tmpfs mounted at /sys/fs/cgroup
I an considering removing the rc_cgroups setting entirely (that is why it is not documented) and creating the /sys/fs/cgroup tmpfs when config_cgroups is on in the kernel. This was only there as a workaround for lxc and a couple of other packages which wanted to mount the cgroup file system at /sys/fs/cgroup which is not how the kernel recommends setting things up.
As far as I can tell mounting these subsystems into seperate directories under /sys/fs/cgroup breaks mounting them into a shared hierarchy somewhere else. I do want a shared hierarchy on my machine, which is why I looked up how to deactivate the subsystem mounting. (use scenario is libvirtd-managed VMs with custom cgroups with n VMs per cgroup instead of per-VM cgroup) If my conception of how this works is wrong please point me to some documentation that clarifies this, if not please do not break my setup ;)
The documentation I am working from is in Documentation/cgroups/cgroup.txt in your linux kernel sources. A shared hierarchy does work, but it seems that the kernel team recommends the other method. Also, other software now expects this method.
have you actually tried using a shared hierarchy as well? I read the documentation, but mounting a shared hierarchy while the "default" mounts were in place invariably failed. It also works without problem for software, as unused components in a group simply get the default values anyways. I can see why some would want seperate hierarchies, but for me it would just complicate things. I am currently on a 3.2 kernel (hardened-sources), so I might be behind the latest development there.
(In reply to comment #4) > have you actually tried using a shared hierarchy as well? > I read the documentation, but mounting a shared hierarchy while the > "default" mounts were in place invariably failed. Yes, I am aware that creating a shared hierarchy fails when the default mounts are in place. > It also works without problem for software, as unused components in a group > simply get the default values anyways. I can see why some would want > seperate hierarchies, but for me it would just complicate things. lxc, libcgroups and systemd all use and expect the default arrangement that openrc uses. It appears that this is becoming the standard expected setup, so that is why I followed it.
I am perfectly fine with that being the default, I just think it should be overridable (currently it is, via rc_cgroups), so that I can choose to have something different. I use cgconfig from libcgroup to mount my hierarchy, and use a libvirtd hook to move VMs to the desired group. If you know a better way to do this I am willing to learn, but until then I am strongly in favour of keeping rc_cgroups.
I think I can make the following changes and make it work: 1) if cgroups is enabled in the kernel, there will always be a /sys/fs/cgroup/openrc group. This will not be linked to a controller, but it will contain all of the processes that OpenRc starts. 2) The name of rc_cgroups will change to rc_controller_cgroups. If this is set to yes, the individual groups for the controllers will be created under /sys/fs/cgroup as they are now. This will default to yes. Thoughts?
reg 2) that is perfectly fine reg 1) sounds good if you can confirm there will be no negative side effects when bug 424405 is fixed (cgconfig running before the very end of openrc startups), especially as cgconfig moves "everything" to a group named "sysdefault".
This is fixed in commit 3df0bd6.
