Messages in this thread | | | From | kamezawa.hiroyu@jp ... | Date | Tue, 15 Jul 2008 00:07:09 +0900 (JST) | Subject | Re: 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
| |