[systemd-devel] [HEADSUP] cgroup changes

[Lennart Poettering]

On Sat, 22.06.13 15:19, Andy Lutomirski (luto at amacapital.net) wrote:

> 1. I put all the entire world into a separate, highly constrained
> cgroup.  My real-time code runs outside that cgroup.  This seems to
> exactly what slices are for, but I need kernel threads to go in to
> the constrained cgroup.  Will systemd support this?

I am not sure whether the ability to move kernel threads into cgroups
will stay around at all, from the kernel side. Tejun, can you comment on this?
> 
> 2. I manage services and tasks outside systemd (for one thing, I
> currently use Ubuntu, but even if I were on Fedora, I have a bunch
> of fine-grained things that figure out how they're supposed to
> allocate resources, and porting them to systemd just to keep working
> in the new world order would be a PITA [1]).
> 
> (cgroups have the odd feature that they are per-task, not per thread
> group, and the systemd proposal seems likely to break anything that
> actually wants task granularity.  I may actually want to use this,
> even though it's a bit evil -- my real-time thread groups have
> non-real-time threads.)

Here too, Tejun is pretty keen on removing the ability of splitting up
threads into cgroups from the kernel, and will only allow this
per-process. Tejun, please comment!

> I think that what I want are something like sub-unit cgroups -- I
> want to be able to ask systemd to further subdivide the group for my
> unit, login session, or whatever.  Would this be reasonable?
> (Another way of thinking of this is that a unit would have a whole
> cgroup hierarchy instead of just one cgroup.)

The idea is not even to allow this. Basically, if you want to partitions
your daemon into different cgroups you need to do that through systemd's
abstractions: slices and services. To make this more palatable we'll
introduce "throw-away" units though, so that you can dynamically run
something as a workload and don't need to be concerned about naming
this, or cleaning it up.

> I think that the single-hierarchy model will require that I
> subdivide my user session so that the default sub-unit cgroup is
> constrained similarly to the default slice.  I'll lose
> functionality, but I don't think this is a showstopper.
> 
> A different approach would be to allow units to (with systemd's
> cooperation) escape into their own, dynamically created unit.  This
> seems kind of awful.

This is basically what I meant with "throw-away" units. 

> 3. My code runs unprivileged, but it still wants to configure
> itself. If needed, I can write a little privileged daemon to handle
> the systemd calls.

So, at least in the beginning I am pretty sure that manipulating the
resource parameters we'll restrict to root-only, since this is much more
security than one might assume and we simply don't oversee this all.

> I think I can get away without anything fancy if a unit (login
> session?) grant the right to manipulate sub-unit cgroups to a
> non-root user.

As mentioned, this will not be possible.

> 4. As mentioned, I'm on Ubuntu some of the time.  I'd like to keep
> the same code working on systemd and non-systemd systems.
> 
> How hard would it be to run systemd as just a cgroup controller?
> That is, have systemd create its slices, run exactly one unit that
> represents the whole system, and let other things use the cgroup
> API.

I have no idea, I don't develop Ubuntu. They will have to come up with
some cgroup maintenance daemon of their own. As I know them they'll
either do a "port" of the systemd counter part (but that's going to be
tough!), or they'll stick something half-baked into Upstart...

Sorry, if this all sounds a bit disappointing. But yeah, this all is not
a trivial change...

Lennart

-- 
Lennart Poettering - Red Hat, Inc.