On Thu, Dec 17, 2015 at 04:54:39PM +0100, Lennart Poettering wrote: > On Thu, 17.12.15 10:44, Colin Walters (walters@xxxxxxxxxx) wrote: > > > On Thu, Dec 17, 2015, at 10:24 AM, Lennart Poettering wrote: > > > > > Can you give realistic examples for these? Can you explain what you > > > are intend to run as PID 1 in them instead? > > > > Nothing, if the pid namespace did zombie collection in the kernel, > > you don't need a separate init. > > hmm? but this is not how Linux works these days, so what's the point > discussing this now? > > Note that PID 1 is in more ways different than just reaping > processes... For example for PID 1, SIGTERM usually is a request for > reexecution, and SIGINT a request for reboot, while for non-PID1 > processes these are requests for termination and cancelling... > > > > What is cleaning up /tmp > > > for those things? > > > > You bind mount the container's /tmp to a host /tmp/container-$uuid > > for example. > > Well, and what sets up all the rest listed in tmpfiles snippets? > > > > What is setting up the tmpfiles bits in /run for > > > them, and so on? > > > > One would carry this in the Dockerfile or equivalent if it applies, > > although it doesn't for a lot of software. > > > > Your broader point is very valid - we're going to need a lot > > of software to run both on the host outside of a container, > > underneath systemd, but we're also trying to enable a > > fully container-only distributed/cluster model via Kubernetes/Docker, > > and in the end microservice state, it just doesn't make sense > > to have a systemd instance per microservice in a cluster. > > Well, that's certainly a opinion on this. I certainly disagree. It > would essentially mean giving up on much what makes up an OS > though, in particular, about half of whatthe packaging guidelines say > what packages shall use and rely on. > > If you want to replace systemd functionality with Docker > functionality, then that's fine, but I think you better make sure you > actually have replacement functionally around. Because otherwise you > just give up on platform design. > > Lennart FWIW, In freight[1], I assume systemd is a member of every container, and that services are started via unit files in the container. Its made generating containers unbelievably easy, in that it doesn't require any additional knoweldge about an application - the way it runs in a container is exactly the way it runs outside of a container, its really nice. [1] http://freightagent.github.io/freight-tools/ > > -- > Lennart Poettering, Red Hat > -- > devel mailing list > devel@xxxxxxxxxxxxxxxxxxxxxxx > http://lists.fedoraproject.org/admin/lists/devel@xxxxxxxxxxxxxxxxxxxxxxx -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx http://lists.fedoraproject.org/admin/lists/devel@xxxxxxxxxxxxxxxxxxxxxxx
