[lxc-devel] [PATCH] Use container specific domain socket name

[Serge Hallyn]

Quoting Dwight Engen (dwight.engen at oracle.com):
> On Tue, 16 Apr 2013 08:52:56 -0500
> Serge Hallyn <serge.hallyn at ubuntu.com> wrote:
> 
> > Quoting S.Çağlar Onur (caglar at 10ur.org):
> > > Hi Serge,
> > > 
> > > I was just following your lead as you said you don't wan't any long
> > > running monitor daemon :)
> > 
> > Yup, at this point I"m going for the least bad solution.  (since the
> > best solution, multicast af_unix, isn't possible :)
> > 
> > > Also I'm not sure how does that daemon is going to help
> > > starting multiple containers concurrently using only API. I'm
> > > guessing the first request will cause that daemon to start and it
> > > will never end unless specifically told it to shutdown?
> > 
> > So basically,
> > 
> >   c1  -                                --> m1
> >         \                             /
> >   c2  ----->  "\0$lxcpath" Daemon -------> m2
> >         /                             \
> >   c3  -/                               --> m3
> > 
> > m1 is the first lxc-monitor someone started.  It sees that
> > "\0$lxcpath" is not bound, so fires off a long-running daemon
> > listening for events on "\0$lxcpath", and doing listen/accept at
> > "\0$lxcpath.M".  Then m1 connects to to that daemon on "\0$lxcpath.M"
> > and listens for events.  m2 starts, connects to "\0$lxcpath.M", and
> > listens for events.  m3. does the same.  m1 exits, but the daemon
> > continues.
> 
> The daemon could keep track of how many monitors are connected and
> exit when the count drops to zero (after waiting some small amount of
> time for a new monitor connection which also handles the initial
> startup case).

Yup that sounds good :)

> This daemon isn't queuing right? So we define that when there is no
> monitor connected, all events are dropped.

Yup, as is the case now.

Anyone want to code a prototype?

-serge