Quoting Brian May (br...@microcomaustralia.com.au): > On 24 October 2013 11:09, Adam Borowski <kilob...@angband.pl> wrote: > > > * it breaks other users of cgroups. I have not tested this personally > > (mostly because of the above point), but if I understand it right, it takes > > over the whole cgroups system, requiring anything that runs on the same > > kernel instance to beg it via dbus to perform required actions. > > > > I have heard this said before, would like to have some official > confirmation if this is actually the case or not. cgroups are currently > hierarchical, I would have thought this would mean, at least in theory, > different programs could be responsible for different parts of > the hierarchy.
It currently can't prevent you from just mounting the cgroupfs and working with it. One of the justifications presented at plumbers for wanting to do this was that changes to a subtree you control can affect other tasks. But it was agreed that that was actually only for realtime (?) cgroup and that it is a bug which must be fixed. In any case, google has released lmctfy (https://github.com/google/lmctfy/) as an alternative cgroup manager which is actually quite nice, and which does support delegation. Based on that I intend to implement a nestable manager. By nestable I mean that it will create a unix socket over which requests can be made. So I can create a container and bind-mount that unix socket into the container. Then a container copy of the same cgroup manager, finding it can't mount cgroups but the device socket exists, makes requests over that socket. If it is in cgroup /c1, and requests creation of socket c2, the host's manager will create /c1/c2. Since we have a unix socket we can check the caller's credentials, it's access(2) rights to the cgroups it wants to manage as well as the tasks it is wanting to move. (And if a container is created inside that container, it can bind-mount the same socket, start another manager, and nesting should just work) I've played enough to verify that all the pieces we need are there. I just haven't had the time to write it, and I need to decide whether/how to base on / integrate with lmctfy. [ And if anyone else wants to write this, please be my guest :) I just want nesting as described above ] -serge -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131024172511.GA21543@ac100
