[systemd-devel] [HEADSUP] cgroup changes

[Andy Lutomirski]

On Mon, Jun 24, 2013 at 6:27 AM, Lennart Poettering
<lennart at poettering.net> wrote:
> On Sat, 22.06.13 15:19, Andy Lutomirski (luto at amacapital.net) wrote:

>>
>> 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]).
>>

[...]

>
>> 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.
>

Hmm.  My particular software can maybe live with this with unpleasant
modifications, but this will break anything that, say, accepts a
connection from a client, forks into a (possibly new) cgroup based on
the identity of that client, and then does something.

How can this support containers or the use of cgroups in a
non-systemwide systemd instance?  Containers may no longer be allowed
to escape from the cgroup they start in, but there should (IMO) still
be a way for things to subdivide their cgroup-controlled resources.

If I want to have a hierarchy more than two levels deep, I suspect I'm
SOL under this model.  If I'm understanding correctly, there will be
slices, then units, and that's it.

>
>> 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...
>

I'm worried that the impedance mismatch between systemd and any other
possible API is going to be enormous.  On systemd, I'll have to:

 - Create a throwaway unit
 - Figure out how to wire up stdout and stderr correctly (I use them
for communication between processes)
 - Translate the current directory, the environment, etc. into systemd
configuration
 - Translate my desired resource controls into systemd's "let's
pretend that there aren't really cgroups underlying it" configuration
 - Start the throwaway unit
 - Figure out how to get notified when it finishes

Without systemd, I'll have to:

 - fork()
 - Ask whatever is managing cgroups to switch me to a different cgroup
 - exec()

This is going to suck, I think.

--Andy