On Wed, 2012-10-17 at 13:18 +0100, Colin Watson wrote: > On Wed, Oct 17, 2012 at 01:07:58PM +0100, James Hunt wrote: > > On 16/10/12 10:07, Colin Watson wrote: > > > On Tue, Oct 16, 2012 at 09:59:11AM +0100, James Hunt wrote: > > >> The current thinking is in fact to have 1 process / user. I think Scott > > >> was suggesting that everything _can_ be handled by PID 1, but whilst > > >> that may be technically true, my view is that the benefits of 1 process > > >> / user outweigh having PID 1 handle everything. > > > > > > Won't this mean that you'll have to have extra complexity to have pid 1 > > > tell the per-user upstart processes about dead processes, since only pid > > > 1 is able to find out about these reliably? You'd need this, for > > > example, to be able to have a respawning user job. > > > > Unclear at this stage: we are still gathering requirements, so no > > concrete design yet. > > > > However, iff the plan is to allow arbitrary amounts of data to be stored > > in a session, I'd prefer that to be external to PID 1 :-) > > I can understand that. I think we need a clear idea of how we're going > to handle things like respawning before the desktop team makes any > concrete plans, though; and preferably with a minimum of complex > plumbing in upstart.
It was my understanding that we could get this by upstart putting all of
the processes in the user session in a cgroup for that user. This would
require upstart to be the first process in the user session, but I think
that's achievable. Is my understanding there incorrect?
--Ted
signature.asc
Description: This is a digitally signed message part
-- ubuntu-desktop mailing list ubuntu-desktop@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
