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

Stéphane Graber stgraber at ubuntu.com
Wed Apr 10 16:30:25 UTC 2013


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.

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

-------------- 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/d1ff80a0/attachment.pgp>


More information about the lxc-devel mailing list