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 -- Lennart Poettering, Red Hat -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx http://lists.fedoraproject.org/admin/lists/devel@xxxxxxxxxxxxxxxxxxxxxxx