[systemd-devel] Systemd and cgroup management (and libcgroup)

[Vivek Goyal]

On Mon, Oct 31, 2011 at 10:32:30PM +0100, Lennart Poettering wrote:
> On Mon, 31.10.11 14:43, Jan Safranek (jsafrane at redhat.com) wrote:
> 
> > >> Even if there is, then it looks like systemd is better place to manage
> > >> it as it already is setting up the whole system and top level hierarchies.
> > >> Thanks to Jason for the suggestion.
> > 
> > Systemd pretty much covers most of the use cases. The main reason to
> > keep separate cgconfig is mounting several controllers together in one
> > hierarchy - AFAIK systemd won't support this mounting. Still, systemd
> > will happily put services to cgroups there.
> 
> We actually do support mounting hierarchies jointly these days. Use
> "JoinControllers=" to achieve that. By default we moint and cpu and
> cpuacct together.
> 
> > Lennart wrote once on previous discussion [1]:
> > 
> > <cite>
> > systemd will create automatic groups for users and services, but will
> > not help you to set up any more complex hierarchy then just 1:1 service
> > to cgroup mappings.
> > 
> > As soon as you want a more complex tree, with multiple levels or
> > something like this you will need something like cgconfig which allows
> > you to create any tree you want.
> > </cite>
> > 
> > Question is, if we really need complex cgroup hierarchies and/or
> > multiple controllers in a hierarchy.
> 
> I am quite sure that sooner or later some folks will need complex cgroup
> hierarchies, for example if they want to give a group "teachers" a more
> resources than the group "students" or so. I am very sure that some
> people want features like that, but I am also quite sure I don't want to
> cover that in systemd, which is why I am happy if cgconfig could fill in
> that void. I think systemd will cover 90% of the use cases, but the 10%
> that are left are valid too, and cgconfig sounds like a useful tool to
> make that work.

I think it is little problematic from user's experience point of view.
For some things/functionality, go talk to systemd or use its APIs and
for rest, go talk to cgconfig/libcgroup.

If systemd is managing users, then it should not be too hard to provide
a command line to put teacher users in specified cgroups and student
users in another specified cgroups.

To me cgconfig infrastructure has a big shortcomings that it can only
create cgroups and after that it can't enforce anything. One can create
"teacher" or "student" cgroups but with a pam plugin, one can't enforce
where these sessions are actually run. We tried to compensate for that
using pam_cgroup pam plugin.

But given the fact that systemd will come with a default policy of putting
every user in a cgroup of its own, any user configuration also becomes
dicy. One needs to override the default settings of systemd.

I think for the sake of better user experience as well as conceptually
it makes sense that systemd takes over all the cgconfig functionality.
I don't think that leaving 10% use cases to cgconfig and let it remain
in a separate subsystem is a good idea. It will conflict with systemd
in various interesting ways and user will atbest be confused then who
to talk to for what functionality.

Especially for me, I am trying to write matahari agent for better cgroup
management. Now if a user wants to change default cgroup of a service, who
should it talk to. This cgroup agent or to the "service" agent. (There is
already a service agent providing basic services like start, stop services
etc).

Thanks
Vivek