[systemd-devel] [HEADSUP] cgroup changes

[Lennart Poettering]

On Mon, 24.06.13 17:09, Andy Lutomirski (luto at amacapital.net) wrote:

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

No. It doesn't do anything that's needed. How do I list all PIDs in a
service with this? How do I determine the service of a PID? How do i do
resource manage with this?

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

Yeah, also the downside that it doesn't do what we need. 

Lennart

-- 
Lennart Poettering - Red Hat, Inc.