On 09/12/13 17:41, Serge Hallyn wrote: > 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? 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 -- upstart-devel mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/upstart-devel
