cgroup stanza a proposal

[Serge Hallyn]

Quoting James Hunt (james.hunt at ubuntu.com):
> On 08/12/13 20:44, Serge Hallyn wrote:
> > 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?
> 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.
> Agreed.
> 
> > 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?
> That was always the general plan. However, PID 1 waits until the forked child
> confirms that all the required child setup has been performed before the

Does that include the pre-start script?  If so, isn't that a problem?

> child execs and Upstart marks the job as running, hence a child that is blocked
> on the cgmanager would block PID 1.
> 
> I am thinking now that the best approach might be to use the autogenerated async
> D-Bus calls in the child and specify a timeout != NIH_DBUS_TIMEOUT_NEVER and

Ok, so that's why you sent that patch :)

This isn't the right list for this, but I do have a question about that
for you.  Are you on the cgmanager mailing list?  I'll move this to there
if/when you are.

> timeout != NIH_DBUS_TIMEOUT_DEFAULT (25 seconds by default fwics). That way, if
> the cgmanager is swamped/dead, we can detect it quickly and report that back to
> PID 1 (which can fail the job) in a timely fashion without blocking PID 1.

Sounds good.

thanks,
-serge