Messages in this thread | | | Date | Fri, 11 Jul 2008 09:55:01 +0900 | From | KAMEZAWA Hiroyuki <> | Subject | Re: [RFC] How to handle the rules engine for cgroups |
| |
On Thu, 10 Jul 2008 11:40:35 -0400 Vivek Goyal <vgoyal@redhat.com> wrote:
> On Thu, Jul 10, 2008 at 10:48:52AM -0400, Rik van Riel wrote: > > On Thu, 10 Jul 2008 02:23:52 -0700 > > "Paul Menage" <menage@google.com> wrote: > > > > > I don't see the rule-based approach being all that useful for our needs. > > > > Agreed, there really is no need for a rule-based approach in kernel space. > > > > There are basically three different cases: > > > > 1) daemons get started up in their own process groups, this can > > be handled by the initscripts > > > > 2) user sessions (ssh, etc) start in their own process groups, > > this can be handled by PAM > > > > 3) users fork processes that should go into special process > > groups - this could be handled by having a small ruleset > > in userspace handle things, right before calling exec(), > > That means application launcher (ex, shell) is aware of the right cgroup > targeted application should go in and then move forked pid to right > cgroup and call exec? Or you had something else in mind? > > > it can even be hidden from the application by hooking into > > the exec() call > > > > This means hooking into libc. So libc will parse rules file, determine > the right cgroup, place application there and then call exec? >
Hmm, as I wrote, the rule that the child inherits its own parent't is very strong rule. (Most of case can be handle by this.) So, what I think of is
1. support a new command (in libcg.) - /bin/change_group_exec ..... read to /etc/cgroup/config and move cgroup and call exec. 2. and libc function - if necessary.
1. is enough because admin/user can write a wrapper script for their applications if "child inherits parent's" isn't suitable.
no ?
Thanks, -Kame
| |