Quoting James Hunt ([email protected]): > 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
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 -- upstart-devel mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/upstart-devel
