cgroup stanza a proposal

[Serge Hallyn]

Quoting James Hunt (james.hunt at ubuntu.com):
> On 29/11/13 18:06, Stéphane Graber wrote:
> > Hello everyone,
> > 
> > I have now published the Cgroup specification on the Upstart wiki:
> > http://upstart.ubuntu.com/wiki/Cgroup
> We've made a few updates to the spec so please let us know if you have any comments.
> 
> Upstart plans to leverage the 'cgmanager' cgroup manager currently being
> developed [1]. This facility is going to be a host-global [2], generic, cgroup
> management system which will handle all cgroup requests. cgmanager will do this
> by providing a (hopefully) standardised API which Upstart will consume.
> 
> Since the design for the cgmanager is still being finalised, we'll need to
> refresh the upstart spec occasionally until that point is reached.
> 
> = Potential Issues =
> 
> == cgroup stanza syntax ==
> 
> As mentioned on [3], the cgroup syntax may change. We need to be very aware of
> this and ensure that a suitable abstraction for the cgroup stanza values is used
> if appropriate. Since the cgmanager authors are already discussing this issue
> with the cgroup kernel subsystem maintainer, we should however get this "for
> free" once the cgmanager spec is finalised.
> 
> == Non-blocking calls ==
> 
> An important consideration from the Upstart side is to ensure that Upstart
> should not block when requesting services from cgmanager. Ideally, the cgmanager
> would offer a callback-type interface to allow upstart to handle cgroup
> creation/deletion events (both requested and indirectly notified).

Rebuttal.  In general if Upstart requests a cgroup to be created, it
will be to start a daemon in that cgroup, right?  So upstart will be
forking a task which will become the daemon.  That task should not
exec until it has been moved into the new cgroup.  So why not have it
request the creation and configuration of the new cgroup, enter the
cgroup, then setresuid and setresgid and finally exec the daemon?

If there's good reason not to do that, then we can certainly add a
callback-type interface.  My limited dbus understanding suggests we'll
just want to send back a dbus signal, but I'm not sure yet.

-serge