On 08/12/13 20:44, Serge Hallyn wrote: > Quoting James Hunt ([email protected]): >> 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 -- upstart-devel mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/upstart-devel
