lkml.org 
[lkml]   [2008]   [Jul]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: Re: [RFC] How to handle the rules engine for cgroups
    ----- Original Message -----
    >On Fri, Jul 11, 2008 at 09:55:01AM +0900, KAMEZAWA Hiroyuki wrote:
    >> 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 nee
    ds.
    >> > >
    >> > > Agreed, there really is no need for a rule-based approach in kernel spa
    ce.
    >> > >
    >> > > 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 ?
    >>
    >
    >If admin has decided to group applications and has written the rules for
    >it then applications should not know anything about grouping. So I think
    >application writing an script for being placed into the right group should
    >be out of question. Now how does an admin write a wrapper around existing
    >application without breaking anything else.
    >
    Sure.

    >One thing could be creating soft links where admin created alias points
    >to wrapper and wrapper inturn invokes the executable. But this will not
    >solve the problem if some user decides to invoke the application
    >executable directly and not use admin created alias.
    >
    yes. It's a hole.

    >Did you have something else in mind when it came to creating wrappers
    >around applications?
    >

    I have no strong idea around this but now it seems

    - handling complicated rules under the kernel will got amount of Nacks.
    (and it seems to add some latency.)
    - We cannot avoid the problem discussed here if we handle the rule in
    userland daemon/process-event-connector.

    So, I wonder adding some limitation may make things simple.

    - application under wrapper will be executed under a group defined by admin.
    - application without wrapper will be executed under a group where exec()
    called.

    A point is that application-without-wrapper is also under Admin's control beca
    use it's executed under a group which calls exec.

    But this is not strict control..this is very loose ;)

    Thanks,
    -Kame



    \
     
     \ /
      Last update: 2008-07-14 17:11    [W:4.440 / U:0.364 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site