Re: systemd effectively mandatory now due to GNOME
Quoting Brian May (brian@microcomaustralia.com.au):
> On 24 October 2013 11:09, Adam Borowski <kilobyte@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
Reply to: