On Mon, Jun 24, 2013 at 4:57 PM, Lennart Poettering <lenn...@poettering.net> wrote: > On Mon, 24.06.13 16:01, Andy Lutomirski (l...@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 _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
