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

[Daniel Lezcano]

On 04/10/2013 09:42 PM, Stéphane Graber wrote:
> On 04/10/2013 08:15 PM, Serge Hallyn wrote:
>> Quoting Christian Seiler (christian at iwakd.de):
>>> Hi there,
>>>
>>>> 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?
>>> Just to throw my 2¢ in there - why not use DBus for that? It seems to me
>>> that DBus has already solved all of the problems that occur here. And
>>> one wouldn't need to care about multi-threading, because one only talks
>>> to the DBus daemon itself.
>> Right, so we'd be using dbus's long-running daemon, so that we don't
>> need our own.  (which I clarify to point out that they didn't "solve
>> this problem" :)
>>
>> I'd actually be ok with this, but Stéphane mentioned he doesn't want
>> dbus to become a dependency.  It seems to me dbus is pretty much
>> ubiquitous anyway, but I trust he has use cases where it would be an
>> undue burden.
>>
>> -serge
> Right, one problem with requiring DBus is for the Android port of LXC on
> which access to a DBus system-bus isn't guaranteed.
>
> I also suspect some people who've been using LXC on restricted/embedded
> platform wouldn't be too happy with us using DBus for our IPC.
>
>
> I however don't think I'd mind us connecting to the DBus system bus and
> exposing our control API on DBus so long as we don't hard depend on it.
>
> I think it's definitely valuable to be able to monitor and control
> containers over DBus and that it'll open a whole set of new
> possibilities and fits rather well with our user namespace work (where
> we'd simply use the session bus), the problem really is about making
> sure lxc-stop/lxc-wait/lxc-... don't depend on a system bus to be setup.
>
> One way to do that is to use something like Upstart did with libnih-dbus
> where we actually have our own builtin DBus server. If we detect a
> system bus, we connect to it and expose everything to it, if we don't,
> we listen on a hard-coded guessable abstract socket but still use the
> DBus protocol.
> The advantage of this is that you don't hard-depend on a system bus,
> systems that don't have it simply connect directly to the abstract
> socket (similar to our existing monitor socket) but still use the exact
> same protocol and path as they'd use against the system bus.
>
>
> One trick however is that DBus is usually designed in a way that a
> single process (daemon) that's either spawned at boot time or
> DBus-activated owns a specific DBus address. In the case of LXC, this
> isn't the case. We'd basically need a separate DBus address for every
> container as we don't actually have a single daemon owning a single
> address on the bus. (As far as I know two processes can't own different
> "paths" on the same "address").
>
>
>
> Yet another proposal I'm just putting out there would be the following:
>  - Keep our monitor protocol mostly as it's, just make it more
> comprehensive, fix known bugs, ...
>  - Create an OPTIONAL long-lasting management daemon
>  - Have LXC poke that daemon on a pre-defined abstract socket when
> initializing. If it's there, then either send the container's socket
> address to that daemon or have lxc-start send status updates back to the
> daemon every time something changes.
>  - Have that daemon own net.sourceforge.lxc (or whatever name we
> register) and expose the DBus API on the system bus.
>  - Update the LXC API to always try using DBus by default and only
> reverting to direct unix sockets if DBus isn't available.
>
> This should give us the following benefits:
>  - Works on system without DBus (with our existing problems)
>  - Offers a "standard" DBus interface to people who want to use it
>  - Transparently integrates with our existing code as an optional
> feature that just makes things more reliable (at the cost of a bit of
> memory/cpu).
>
> Obviously this comes at the cost of having to code and maintain said
> daemon and updating the API to handle the DBus/socket fallback.

Sorry for jumping so late in the thread but I disagree to use DBUS with
LXC because of the dependency with more packages, LXC has been designed
to be stand alone, nothing prevent to add more complexity and
dependencies but on top of LXC not inside.

To answer the previous email Serge sent me, I thought a bit about the
mechanism in order to prevent a publish/subscribe approach. The first
version used the af_netlink socket to use some kind of message multicast
on processes. But it hacked a family of the netlink which was
conflicting with the ip_route tool. In order to prevent this conflict I
switched "temporarly" to the AF_UNIX socket while looking for a socket
type matching our needs. The AF_IPN (Inter Process Network) could have
been perfect but the patchset has been rejected.

I think the solution to solve this issue is to use the AF_INET protocol
on the loopback using the loopback's broadcast address and filter the
messages with the container name. The code should be 'trivial'.

One question remains with this approach : which communication port number ?