On Thu, Dec 17, 2015 at 04:54:39PM +0100, Lennart Poettering wrote:
On Thu, 17.12.15 10:44, Colin Walters (walters@verbum.org) 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@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org