On Fri, 02.05.14 12:54, Daniel J Walsh ([email protected]) wrote: > > > On 05/02/2014 11:54 AM, Lennart Poettering wrote: > > On Wed, 30.04.14 14:21, Daniel J Walsh ([email protected]) 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.
It really shouldn't mount all of /proc read-oony, just /proc/sys and /sys. But apps should be allowed to get write access to /proc/self/ and friends, there are some things in there, that should be writable. The read-only mounting should happen in all kinds of containers, priviliged and non-priviliged... > > 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. I added this to the todo list now. > 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 All of journald's communication is via sockets in the fs. There's /dev/log for syslog, /run/journal/systemd/socket for the native protocol, and /run/journal/systemd/stdout for the stdout/stderr thing. In theory it should suffice to bind mount these sockets fromt he host. In real life though the dependency tree in the container will still try to invoke a journald for you... Lennart -- Lennart Poettering, Red Hat _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
