[systemd-devel] dbus interface for disabling default cgroups
lennart at poettering.net
Mon Feb 14 09:20:49 PST 2011
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
> > 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
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
Well, my famous shell fragment already kinda did that. As well as the
autogrouping patch that got merged.
Lennart Poettering - Red Hat, Inc.
More information about the systemd-devel