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

[Serge Hallyn]

Quoting Stéphane Graber (stgraber at ubuntu.com):
> On 04/10/2013 06:43 PM, Serge Hallyn wrote:
> > Quoting Stéphane Graber (stgraber at ubuntu.com):
> >> On 04/10/2013 06:49 AM, Serge Hallyn wrote:
> >>> Quoting S.Çağlar Onur (caglar at 10ur.org):
> >>>> Hi Serge,
> >>>>
> >>>> On Tue, Apr 9, 2013 at 4:47 PM, Serge Hallyn <serge.hallyn at ubuntu.com>wrote:
> >>>>
> >>>>> All right you made me finally take a closer look at the monitor code
> >>>>> (which I'd been avoiding).  It's much simpler than I'd imagined.  So
> >>>>> here are the challenges:
> >>>>>
> >>>>> 1. lxc-monitor should be able to watch 'all containers' (at least under
> >>>>> a given lxcpath).  That is actually the strong reason to object to your
> >>>>> patch.
> >>>>>
> >>>>
> >>>> Ah, that makes sense.
> >>>>
> >>>>
> >>>>> 2. we don't want to force any long-running daemon to run as the monitor.
> >>>>> 3. we want to allow multiple containers to send state change info
> >>>>> to multiple simulataneous lxc-monitor and lxc-wait listeners.
> >>>>>
> >>>>> Now I can think of some whacky solutions, but are there any simple ones
> >>>>> I'm overlooking?
> >>>>
> >>>>
> >>>> I'm not sure what is your whacky solution but if I'm not missing something
> >>>> this sounds like multicast :) I'm sorry for my ignorance but did multicast
> >>>> unix sockets patch set find its way into upstream kernel?
> >>>
> >>> It looks to be a tough sell to the networking maintainer :)
> >>>
> >>> http://lkml.org/lkml/2012/2/28/369
> >>>
> >>> -serge
> >>
> >> So my basic plan for the monitor was to allow multiple connections to
> >> the socket with the easiest way of doing that being to use
> >> multithreading, spawning a thread for each connection.
> > 
> > Who's doing this thread-spawning?  You're assuming a long-running
> > daemon, which violates #2 above.  If we're ok with that, then that
> > definately simplifies things.
> 
> lxc-start is already a long-running "daemon" which listens on the unix
> socket, all we'd need is to have it spawn a new thread for each
> connection instead of processing the monitor command itself.

Let's say I do

	sudo lxc-monitor -n r1 -n r2

and now do

	sudo lxc-start -n r1

How do we know to send the 'started' event to the lxc-monitor, since
there was not yet a lxc-start daemon running?

-serge