[systemd-devel] Blog on running systemd within a docker container.

[Lennart Poettering]

On Wed, 30.04.14 14:21, Daniel J Walsh (dwalsh at redhat.com) wrote:

> http://rhatdan.wordpress.com/2014/04/30/running-systemd-within-a-docker-container/

There are a couple of things in the story that I'd like to correct:

1) udev isn't actually started when systemd detects that /sys is read-only. See:

http://www.freedesktop.org/wiki/Software/systemd/ContainerInterface/

The idea here is that docker should mount /sys read-only (already for
for security purposes it should do that). When that's done udev is not
started, and that requires no explicit work by you. I's conditionalized
via ConditionPathIsWritable=/sys.

2) systemd doesn't even start getty logins (plural!). If it detects it
runs inside a container it will actually start exactly one, on
/dev/console. We can improve systemd to find out a way how to even
disable that. For example, we could build on $container_ttys (see the
url above), and maybe intrdouce $container_headless=1 or so, which when
set will result in systemd to not start any getty at all.

3) THis is similar for all the other .wants/ links you remove. I think
we really should avoid doing this. Instead, it sounds better to make
sure systemd automatically figures out when to start specific services
and when to not do that. As it turns out we did this for quite a few of
the services in there already. For example, systemd-binfmt is already
skipped if /proc/sys is not writable anyway... And so on. So instead of
doing blanket removals, please let us know which ones you see running
that you'd rather not see running, and we can figure out a way how to
conditionaliuze them upstream so that unmodified systemd just works for
you...

To say this explicitly: we are really interested in making sure that
systemd runs out-of-the-box in containers, and docker is just one
implementation of that.

Lennart

-- 
Lennart Poettering, Red Hat