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

[Stéphane Graber]

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.

>> There are other ways to deal with non-blocking reads on multiple sockets
>> (basically an infinite loop of accept/read without threading) which we
>> may want to look into if we want to avoid threading.
>>
>>
>> Now, having that information broadcast may have its value, but I think
>> in LXC itself, we should probably stick to unicast and leave
>> broadcasting this to an external piece of software which would use our
>> API to monitor all the containers and provide some kind of bridge to DBus.
>> The current obvious "multi-casty" thing on the Linux desktop is DBus and
>> while we could theoretically use it as a replacement for our current
>> unix socket, I don't really think we want to bring it as a dependency
>> for LXC.
>>
>>
>> -- 
>> Stéphane Graber
>> Ubuntu developer
>> http://www.ubuntu.com
>>
> 
> 
> 
>> ------------------------------------------------------------------------------
>> 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 at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/lxc-devel
> 


-- 
Stéphane Graber
Ubuntu developer
http://www.ubuntu.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 901 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxcontainers.org/pipermail/lxc-devel/attachments/20130410/0a49935b/attachment.pgp>