[systemd-devel] dbus interface for disabling default cgroups

[Lennart Poettering]

On Mon, 14.02.11 18:12, Daniel Poelzleithner (poelzi at poelzi.org) wrote:

> On 02/14/2011 05:04 PM, Lennart Poettering wrote:
> 
> > I am not sure I actually buy that. I kinda like the fact that sending a
> > signal to the gnome-shell process group delivers a signal to all
> > processes it spawned.
> 
> But every program that execs another process may call setgrp on it's
> child. Most shells for example do that, and console apps as well. Some
> processes started by gnome-session run setsid and end up with different
> task groups anyway, so you will never catch all.

Yeah, the chaos of what the various processes started by g-s do to
detach from g-s is awful. we hope to clean this up a little with
PR_SET_ANCHOR.

> > Well, this remains a hack, and the higher your raise that value the more
> > obvious it becomes: since all your slices summed up need to be < your
> > period length you limit how many services/apps you can start. Since the
> > period length by default is 1s, sending the runtime length to 1ms means
> > you enforce a hard limit of 1000 groups controlled by you.
> > 
> > In short: this doesn't work. Fix the kernel. Don't try to work around
> > broken kernel APIs in userspace.
> 
> As long as it's not fixed, I don't see any other solution :-)

Well the solution is to fix it then.

> > Uh, this sounds wrong. You apply "rules" asynchronously on processes?
> > How do you do that? With cn_proc? This is ugly and broken. Wasn't right
> > in Upstart and is still broken outside of Upstart.
> 
> I use cn_proc as notifications for new processes and exits. I don't use
> it for tracking where a process originated from, so it works quite nice
> for this case. Using cgroups to find the origin is of course a much
> better solution and cn_proc will not work there. But as I currently
> don't care about origins, and in fact only schedule it when a process is
> at least one second old, the cn_proc interface is much more suited then
> cgroups.

But that means you apply your cgroup magic only a posterio. That is by
definition unsafe and unreliable. Using async interfaces for stuff like
this is always broken.

> >>> The need for configuration is a bad thing, not a good thing. Where we
> >>> can we should create systems that just work.
> >>
> >> I really think that "one configuration fits all" will just not work
> >> until proven otherwise :-)
> > 
> > I believe we can get very very far without any heuristics and configured
> > rules. So far you haven't listed any valid usecase where we couldnt come
> > up with a generic logic that would work for everybody.
> 
> Example: i use the process group as the default grouping value which
> works extremely good. Processes that belong together are usually in one
> group, so one group of processes can't overload the system.
> gnome-panel & kde don't set the process group, so i need a rule for
> that. With the current configuration i can run a make -j 40 on the linux
> kernel on my dual core and do not notice any slowdown, it's still smooth
> everywhere.

Well, my famous shell fragment already kinda did that. As well as the
autogrouping patch that got merged. 

Lennart

-- 
Lennart Poettering - Red Hat, Inc.