From: kamezawa.hiroyu@jp.fujitsu.com
To: Vivek Goyal <vgoyal@redhat.com>
Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
Rik van Riel <riel@redhat.com>, Paul Menage <menage@google.com>,
linux kernel mailing list <linux-kernel@vger.kernel.org>,
Libcg Devel Mailing List <libcg-devel@lists.sourceforge.net>,
Balbir Singh <balbir@linux.vnet.ibm.com>,
Dhaval Giani <dhaval@linux.vnet.ibm.com>,
Peter Zijlstra <pzijlstr@redhat.com>,
Kazunaga Ikeno <k-ikeno@ak.jp.nec.com>,
Morton Andrew Morton <akpm@linux-foundation.org>,
Thomas Graf <tgraf@redhat.com>,
Ulrich Drepper <drepper@redhat.com>
Subject: Re: Re: [RFC] How to handle the rules engine for cgroups
Date: Tue, 15 Jul 2008 00:07:09 +0900 (JST) [thread overview]
Message-ID: <1357735.1216048029837.kamezawa.hiroyu@jp.fujitsu.com> (raw)
In-Reply-To: <20080714135719.GE16673@redhat.com>
----- 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
next prev parent reply other threads:[~2008-07-14 15:08 UTC|newest]
Thread overview: 60+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-07-01 19:11 [RFC] How to handle the rules engine for cgroups Vivek Goyal
2008-07-02 9:33 ` Kazunaga Ikeno
2008-07-03 1:19 ` KAMEZAWA Hiroyuki
2008-07-03 15:54 ` Vivek Goyal
2008-07-04 0:34 ` KAMEZAWA Hiroyuki
2008-07-04 3:17 ` Li Zefan
2008-07-08 9:35 ` Balbir Singh
2008-07-08 13:45 ` Vivek Goyal
2008-07-10 9:23 ` Paul Menage
2008-07-10 14:30 ` Vivek Goyal
2008-07-10 15:42 ` Dhaval Giani
2008-07-10 16:51 ` Paul Menage
2008-07-10 14:48 ` Rik van Riel
2008-07-10 15:40 ` Vivek Goyal
2008-07-10 15:56 ` Ulrich Drepper
2008-07-10 17:25 ` Rik van Riel
2008-07-10 17:39 ` Ulrich Drepper
2008-07-10 18:41 ` Vivek Goyal
2008-07-10 22:29 ` Ulrich Drepper
2008-07-11 0:55 ` KAMEZAWA Hiroyuki
2008-07-14 13:57 ` Vivek Goyal
2008-07-14 14:44 ` David Collier-Brown
2008-07-14 15:21 ` Vivek Goyal
2008-07-17 7:05 ` Kazunaga Ikeno
2008-07-17 13:47 ` Vivek Goyal
[not found] ` <20080717170717.GA3718@linux.vnet.ibm.com>
2008-07-18 8:12 ` [Libcg-devel] " Dhaval Giani
2008-07-18 20:12 ` Vivek Goyal
2008-08-17 10:33 ` [RFC] [PATCH -mm] cgroup: uid-based rules to add processes efficiently in the right cgroup Andrea Righi
2008-08-18 12:35 ` Vivek Goyal
2008-08-19 14:35 ` righi.andrea
2008-08-18 21:05 ` Paul Menage
2008-08-19 12:57 ` Vivek Goyal
2008-08-26 0:54 ` Paul Menage
2008-08-26 13:41 ` Vivek Goyal
2008-08-26 14:35 ` Balbir Singh
2008-08-26 15:04 ` David Collier-Brown
2008-08-26 16:00 ` Vivek Goyal
2008-08-26 16:32 ` David Collier-Brown
2008-08-26 16:08 ` Vivek Goyal
2008-09-04 18:25 ` Paul Menage
2008-08-19 15:12 ` righi.andrea
2008-08-26 0:55 ` Paul Menage
2008-07-14 15:07 ` kamezawa.hiroyu [this message]
2008-07-10 9:07 ` [RFC] How to handle the rules engine for cgroups Paul Menage
2008-07-10 14:06 ` Vivek Goyal
2008-07-10 16:41 ` Paul Menage
2008-07-10 17:19 ` Vivek Goyal
2008-07-10 17:27 ` [Libcg-devel] " Dhaval Giani
2008-07-10 14:33 ` Vivek Goyal
2008-07-10 16:46 ` Paul Menage
2008-07-10 17:18 ` [Libcg-devel] " Dhaval Giani
2008-07-10 17:30 ` Paul Menage
2008-07-10 17:44 ` Dhaval Giani
2008-07-10 15:49 ` Dhaval Giani
2008-07-18 9:52 ` KAMEZAWA Hiroyuki
2008-07-18 15:46 ` Paul Menage
2008-07-18 16:39 ` Balbir Singh
2008-07-18 18:55 ` Vivek Goyal
2008-07-18 23:05 ` kamezawa.hiroyu
2008-07-18 23:10 ` kamezawa.hiroyu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1357735.1216048029837.kamezawa.hiroyu@jp.fujitsu.com \
--to=kamezawa.hiroyu@jp.fujitsu.com \
--cc=akpm@linux-foundation.org \
--cc=balbir@linux.vnet.ibm.com \
--cc=dhaval@linux.vnet.ibm.com \
--cc=drepper@redhat.com \
--cc=k-ikeno@ak.jp.nec.com \
--cc=libcg-devel@lists.sourceforge.net \
--cc=linux-kernel@vger.kernel.org \
--cc=menage@google.com \
--cc=pzijlstr@redhat.com \
--cc=riel@redhat.com \
--cc=tgraf@redhat.com \
--cc=vgoyal@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).