<i>One of these is killing "zombie" processes that have been abandoned by their calling session.</i><p>That's funny terminolgy, isn't it? Killing a process usually means sending it a signal, typically TERM or KILL, that causes it to exit. But a zombie process is one that has already exited, but hasn't been waited for by its parent, where its parent is either the process that spawned it, or if that process has died, the process with PID 1. This is usually referred to as reaping the zombie process, not killing it. AFAIK, a signal sent to a zombie process is simply ignored.<p>Or do the quotes around zombie imply a different meaning, such as "zombie-like"?
<i>Poettering says that PID 1 has special requirements. One of these is killing "zombie" processes that have been abandoned by their calling session. This is a real problem for Docker since the application runs as PID 1 and does not handle the zombie processes. For example, containers running the Oracle database can end up with thousands of zombie processes.</i><p>Why does Poettering keep claiming this when he's the one who submitted the patch that adds the PR_SET_CHILD_SUBREAPER prctl(2) [0] functionality?<p>[0] <a href="http://man7.org/linux/man-pages/man2/prctl.2.html" rel="nofollow">http://man7.org/linux/man-pages/man2/prctl.2.html</a>
why not systemd-nspawn (zoidberg voice)<p>Seems like the way Fedora is packaging systemd for 24 is going to move systemd-nspawn to a level of maturity that will likely surpass some of the clunky issues folks have with running docker.
I don't always run containerized applications, but when I do, I prefer them completely systemd-free, thank you.<p>Sometimes I wonder if systemd is actually a part of big plan of moving everyone to microservices and containers and maybe even unikernels — anything, just anything without this abomination.