The word "subreaper" is used in some answers. Searching Google also turn up entries where the word is "just used".
How can I understand what a "subreaper" is?
[...] A subreaper fulfills the role of
init(1)for its descendant processes. Upon termination of a process that is orphaned (i.e., its immediate parent has already terminated) and marked as having a subreaper, the nearest still living ancestor subreaper will receive a
SIGCHLDsignal and be able to
wait(2)on the process to discover its termination status.
A process can define itself as a subreaper with
prctl(PR_SET_CHILD_SUBREAPER). If so, it's not
init (PID 1) that will become the parent of orphaned child processes, instead the nearest living grandparent that is marked as a subreaper will become the new parent. If there is no living grandparent,
The reason to implement this mechanism was that userspace service managers/supervisors (like
systemd) need to track their started services. Many services daemonize by double-forking and get implicitly re-parented to PID 1. The service manager will no longer be able to receive the
SIGCHLD signals for them, and is no longer in charge of reaping the children with
wait(). All information about the children is lost at the moment PID 1 cleans up the re-parented processes. Now, a service manager process can mark itself as a sort of "sub-init", and is now able to stay as the parent for all orphaned processes created by the started services. All
SIGCHLD signals will be delivered to the service manager.
In Linux, a daemon is typically created by forking twice with the intermediate process exiting after forking the grandchild. This is a common technique to avoid zombie processes. The init script calls a child. That child forks again and thus exits immediately. The grandchild will be adopted by
init, which continuously calls
wait() to collect the exit status of his children to avoid zombies. With the concept of subreapers, the userspace service manager now becomes the new parent, instead of