cgroup stanza a proposal

[James Hunt]

On 09/12/13 17:41, Serge Hallyn wrote:
> 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?
I was generalising above - Upstart will perform these child checks for every job
process (pre-star, post-stop, etc).

> 
>> 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.
I am :)

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

Kind regards,

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