Messages in this thread | | | Date | Mon, 14 Jul 2008 09:57:19 -0400 | From | Vivek Goyal <> | Subject | Re: [RFC] How to handle the rules engine for cgroups |
| |
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 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 ? >
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.
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.
Did you have something else in mind when it came to creating wrappers around applications?
Thanks Vivek
| |