On Wed, 30.04.14 14:21, Daniel J Walsh (dwa...@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 _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
