Quoting Stéphane Graber (stgra...@ubuntu.com):
> On 04/10/2013 06:43 PM, Serge Hallyn wrote:
> > Quoting Stéphane Graber (stgra...@ubuntu.com):
> >> On 04/10/2013 06:49 AM, Serge Hallyn wrote:
> >>> Quoting S.Çağlar Onur (cag...@10ur.org):
> >>>> Hi Serge,
> >>>>
> >>>> On Tue, Apr 9, 2013 at 4:47 PM, Serge Hallyn
> >>>> <serge.hal...@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
------------------------------------------------------------------------------
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis & visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter
_______________________________________________
Lxc-devel mailing list
Lxc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-devel
