On Fri, May 02, 2014 at 12:54:25PM -0400, Daniel J Walsh wrote: > > On 05/02/2014 11:54 AM, Lennart Poettering wrote: > > 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. > There is a pull request to mount /proc and /sys as readonly that looks > like it is going upstream soon. The readonly mount will only happen in > non-priv containers. Once we have the ability to add SYS_ADMIN > capability to a non-priv container, I should be able to run systemd > inside a container and this should work. > > 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. > I think this would be good, since we plan on using nsenter to join > containers, don't think we want getty/login running there by default. > > 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... > Once we have a better docker, and I can run systemd in a non priv > container, I will attempt this again, and see what processes get started > without the cleanups in the .wants directories. I too would like to get > rid of these. > > 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 > > > Great, and I want to make systemd the default tool for running multiple > services within a docker container. I like it for running a single > service also, since it is so simple. I would like to talk to you guys > about getting the "journal" information out of the container. IE with > this model we loose STDOUT/STDERR and /dev/log entries showing up in the > hosts journal. We can bind mount /dev/log into the container, but we > still loose STDOUT/STDERR You can check systemd-nspawn and the "--link-journal" switch, if set to "host" the journal '/var/log/journal/machine-id' will be stored on host, and bind mounted into the container.
Thanks for the blog! -- Djalal Harouni http://opendz.org _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
