[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130715184940.GG27338@redhat.com>
Date: Mon, 15 Jul 2013 14:49:40 -0400
From: Vivek Goyal <vgoyal@...hat.com>
To: Michal Hocko <mhocko@...e.cz>
Cc: Tejun Heo <tj@...nel.org>, Tim Hockin <thockin@...kin.org>,
Mike Galbraith <bitbucket@...ine.de>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Containers <containers@...ts.linux-foundation.org>,
Kay Sievers <kay.sievers@...y.org>,
lpoetter <lpoetter@...hat.com>,
workman-devel <workman-devel@...hat.com>,
"dhaval.giani" <dhaval.giani@...il.com>,
Cgroups <cgroups@...r.kernel.org>,
bsingharora <bsingharora@...il.com>
Subject: Re: [Workman-devel] cgroup: status-quo and userland efforts
On Sun, Jun 30, 2013 at 08:38:38PM +0200, Michal Hocko wrote:
> On Fri 28-06-13 14:01:55, Vivek Goyal wrote:
> > On Fri, Jun 28, 2013 at 05:05:13PM +0200, Michal Hocko wrote:
> [...]
> > > OK, so libcgroup's rules daemon will still work and place my tasks in
> > > appropriate cgroups?
> >
> > Do you use that daemon in practice?
>
> I am not but my users do. And that is why I care.
Michael,
would you have more details of how those users are exactly using
rules engine daemon.
To me rulesengined processed 3 kinds of rules.
- uid based
- gid based
- exec file path based
uid/gid based rule exection can be taken care by pam_cgroup module too.
So I think one should not need cgrulesengined for that.
I am curious what kind of exec rules are useful. Any placement of
services one can do using systemd. So only executables we are left
to manage are which are not services.
In practice is it very useful for an admin to say if "firefox" is launched
by a user then it should run in xyz cgroup. And if user cares about
firefox running in a sub cgroup, then it can always use cgexec to do
that.
Thanks
Vivek
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists