Re: [PATCH] prctl.2: Document new PR_SET_CHILD_SUBREAPER semantics

From: Pavel Tikhomirov
Date: Sat Jan 28 2017 - 01:39:25 EST

On 01/28/2017 01:47 AM, Michael Kerrisk (man-pages) wrote:
Hello Pavel,

On 27 January 2017 at 23:11, Pavel Tikhomirov <ptikhomirov@xxxxxxxxxxxxx> wrote:
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

When did the kernel behavior change?

Sorry for inconvenience, should have added you to cc of a main patch also.

Kernel behavior haven't changed yet, doc change will be a continuation of "[PATCH v2 0/2] prctl: make PR_SET_CHILD_SUBREAPER deterministic", see



Signed-off-by: Pavel Tikhomirov <ptikhomirov@xxxxxxxxxxxxx>
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
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.
.BR PR_GET_CHILD_SUBREAPER " (since Linux 3.4)"
Return the "child subreaper" setting of the caller,

Best regards, Tikhomirov Pavel
Software Developer, Virtuozzo.