>There is no objective basis for such a claim, this not actually being a
>minimal requirement of process #1. Welcome to the future. Your service
>manager does not have to be process #1. Your interactive logins are
>ordinary services controlled by your service manager. Orphaned child
>processes are reparented to your service manager or to some other
>process that is even closer to them.
I'm still waiting for someone to show me tangible benefits to declaring
subreapers.
An orphan child has nobody to report its exit code to. Nobody cares
*how* exactly an orphan dies. A reaper, be it pid 1 or something else,
cannot do anything with the wstat it gets from all the orphans it reaps;
it can only lay zombies to rest, and that's it. The only process that
can benefit from a child's exit code is the child's direct parent,
because it knows how to interpret it, and *no* other process does.
As far as I can see, it does not matter in the slightest who's in
charge
of orphans: it's purely a convention. And so, subreapers are a perfectly
useless addition to Unix, with the dubious benefits of being cool and
new,
and the proven drawbacks of being non-standard, harming portability and
adding needless complexity to code that falls into the trap of using
them.
You want a clean process tree with a visually pleasing "ps afuxww"
output? Fix your services so they don't leave orphans in the first
place. Is that impossible? Use process groups to identify what service
the orphans were originally spawned from: if needed, you can send a
signal to the whole process group, and it will reach all the processes
in the service, including orphans.
Reparenting orphans to anything else than the default is a backwards
way to solve a nonexistent problem.
Note that s6 will work in containers, for instance with s6-overlay as
John mentioned. Unlike runit, it also allows you to customize what it
does on receipt of a SIGTERM.
--
Laurent
Received on Wed Feb 01 2017 - 16:48:15 UTC