[systemd-devel] [HEADSUP] cgroup changes

[Andy Lutomirski]

On Mon, Jun 24, 2013 at 4:57 PM, Lennart Poettering
<lennart at poettering.net> wrote:
> On Mon, 24.06.13 16:01, Andy Lutomirski (luto at amacapital.net) wrote:
>
>> AFAICT the main reason that systemd uses cgroup is to efficiently
>> track which service various processes came from and to send signals,
>> and it seems like that use case could be handled without cgroups at
>> all by creative use of subreapers and a syscall to broadcast a signal
>> to everything that has a given subreaper as an ancestor.  In that
>> case, systemd could be asked to stay away from cgroups even in the
>> single-hierarchy case.
>
> systemd uses cgroups to manage services. Managing services means many
> things. Among them: keeping track of processes, listing processes of a
> service, killing processes of a service, doing per-service logging
> (which means reliably, immediately, and race-freely tracing back
> messages to the service which logged them), about 55 other things, and
> also resource management.
>
> I don't see how I can do anything of this without something like
> cgroups, i.e. hierarchial, resource management involved systemd which
> allows me to securely put labels on processes.

Boneheaded straw-man proposal: two new syscalls and a few spare processes.

int sys_task_reaper(int tid): Returns the reaper for the task tid
(which is 1 if there's no subreaper).  (This could just as easily be a
file in /proc.)

int sys_killall_under_subreaper(int subreaper, int sig): Broadcasts
sig to all tasks under subreaper (excluding subreaper).  Guarantees
that, even if those tasks are forking, they all get the signal.

Then, when starting a service, systemd forks, sets the child to be a
subreaper, then forks that child again to exec the service.

Does this do everything that's needed?  sys_task_reaper is trivial to
implement (that functionality is already there in the reparenting
code), and sys_killall_under_subreaper is probably not so bad.


This has one main downside I can think of: it wastes a decent number
of processes (one subreaper per service).

--Andy