[systemd-devel] Waiting for nspawn services

Rich Freeman r-systemd at thefreemanclan.net
Mon Oct 27 08:49:53 PDT 2014


On Mon, Oct 27, 2014 at 11:32 AM, Lennart Poettering
<lennart at poettering.net> wrote:
> Network namespaces are relevant for the process that originally binds
> the sockets. In the case of socket-activated containers that would be
> the host. If you then pass the fds into the containers and those are
> locked into their own namespaces, then any sockets they create and
> bind would be from their own namepsace, but the one they got passed in
> would still be from the original host namespace. If they then accept a
> connection on that passed-in socket that connection socket would also
> be part of the same host namespace -- not of the containers.
>

In case it wasn't clear - I'm talking about network namespaces with
ethernet bridging - not just an isolated network namespace without any
network access at all.  That said, I could certainly see why the
latter would be useful.

So, if the host is 10.0.0.1, then mysql would normally listen on
10.0.0.2:3306.  One of my goals here was to keep everything running on
its native port and dedicated IP to minimize configuration.  For
example, I can run ssh on 10.0.0.2 and let it have port 22, and not
worry about the other 3 containers running ssh on port 22.

I suppose I could have systemd listen on 10.0.0.1:x and pass that
connection over to mysql.  However, then I need to point services to
10.0.0.1 and not 10.0.0.2.

This is why I alluded to it being useful to be able to depend on
services on remote hosts.  I completely agree that doing this in a
clean way without resorting to polling would involve a bit of work.
My own workaround in this case was basically going to amount to
polling.

--
Rich


More information about the systemd-devel mailing list