cgroup stanza a proposal

[James Hunt]

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
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
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.

> 
> 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
> 

Kind regards,

James.
--
James Hunt
____________________________________
#upstart on freenode
http://upstart.ubuntu.com/cookbook
https://lists.ubuntu.com/mailman/listinfo/upstart-devel