old semantics was non deterministic and worked differently depending on the external factors, but nothing changes if process first sets itself subreaper and only after forks
Signed-off-by: Pavel Tikhomirov <ptikhomi...@virtuozzo.com> --- man2/prctl.2 | 24 +++++++++++++++++------- 1 file changed, 17 insertions(+), 7 deletions(-) diff --git a/man2/prctl.2 b/man2/prctl.2 index 97cf21a..84fbd7e 100644 --- a/man2/prctl.2 +++ b/man2/prctl.2 @@ -162,20 +162,30 @@ if is zero, unset the attribute. When a process is marked as a child subreaper, -all of the children that it creates, and their descendants, +all of the children that it creates or have created already, and their descendants, will be marked as having a subreaper. In effect, a subreaper fulfills the role of .BR 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 +Upon termination of a process having a subreaper, +all its children become orphaned +and will be reparented to the nearest still living ancestor subreaper. +So that on it's adopted child termination +these subreaper will receive a .BR SIGCHLD signal and will be able to .BR wait (2) -on the process to discover its termination status. +on the child to discover its termination status. + +Note, that on older kernels these prctl works slightly different. +Child subreaper process was not actualy the +.BR init (1) +for all its descendants. +If process forks a child while not been a child subreaper, +and after sets himself child subreaper, +sub-tree of the child might or might not reparent to the subreaper, +depending on the configuration of ancestors of the subreaper, +at the time of forking our subtree. .TP .BR PR_GET_CHILD_SUBREAPER " (since Linux 3.4)" Return the "child subreaper" setting of the caller, -- 2.9.3
