[systemd-devel] Waiting for nspawn services

[Lennart Poettering]

On Sat, 25.10.14 05:39, Rich Freeman (r-systemd at thefreemanclan.net) wrote:

> One of the useful options in nspawn is the ability to boot the init
> within the container using -b, especially if that init happens to be
> systemd.
> 
> However, I could not find any easy way to set a dependency on a
> service within a container.
> 
> Example use case:
> Unit 1 boots an nspawn container that runs mysql
> Unit 2 launches a service that depends on mysql, or it might even be
> another container that depends on mysql.
> 
> I could put together a script that pings mysql until it is up, but the
> original mysql unit already has to make the determination as to
> whether the service is ready, so this is redundant.  Also, that is a
> solution specific to a single daemon, while the problem is generic.
> 
> I could think of a few possible ways to solve this.
> 
> 1.  Have a way to actually specify a dependency on a unit within a
> container.

As I see it containers are really about separation of things, and
integrating multiple systemd nodes into a single dependency tree
appears a slippery slope to me here...

> 2.  Have a generic wait program that can wait for any unit to start
> within a container, or perhaps even on a remote host.

Note that a tool like this would have to do the
try-wait-try-again-repeat dance as well, as init systems are not
immediately connectable when a container is booted, during their early
boot phase. 

> 3.  Have a way for nspawn to delay becoming online until all services
> inside have become online.
> 
> Actually, being able to express unit dependencies across machines
> might be useful on many levels, but I'll be happy enough just to be
> able to handle containers on a single host for now.

I am not opposed to adding a scheme that makes this possible, but I am
not sure how we could do this in a nice way. Requirements I see are:
that it fails gracefully on non-systemd guests, is race-free, doesn't
involve retry loops.

In general I think making use of socket notification here would be the
much better option, as it removes the entire need for ordering things
here. nspawn already support socket activation just fine. If your
mysql container would use this, then you could start the entire mysql
container at the same time as the mysql client without any further
complexity or synchronization, and it would just work.

socket activation in mysql would be pretty useful anyway, so maybe
that's the more preferable option anyway?

Lennart

-- 
Lennart Poettering, Red Hat