This whole debate saddens me

> How about an alternative to what systemd proposed for managaement of cgroups (that is, a systemd, pid=1 dependent solution). How about systemd learning to live and cooperate in an ecosystem that is based on UNIX philosophy ?
I'm extremely worried about cgroups interoperability. There was a plan for systemd to own ALL of the cgroups and even forbid their modifications by other processes on the kernel level.

However, it seems that somebody had repeatedly beaten kernel cgroups maintainers with a cluebat. So it'll be possible to carve out a subtree out of the cgroups tree and manage it with any tool you want. Even perhaps namespace it for a custom container.

> The monitoring process need only handle the SIGCLD signal. Not only is this very easy to do, but it doesn't need any special permissions or non-standard configurations either.
No, it's not. SIGCHLD is woefully inadequate for process confinement. Only the _parent_ receives it.

For example, suppose that BIND11 launches a helper program 'zone_from_mongodb'. This program (in error!) launches a mongodb instance in the background. Mongodb does the regular daemon song-and-dance and reparents itself to the PID1.

But here's the catch - PID1 has no way to know that this mongodb process actually belongs to BIND11! So there'll be no way to terminate BIND11 cleanly - we'll leave a mongodb instance running in background.

So no, SIGCHLD is not nearly enough.