On Fri, Mar 1, 2013 at 9:36 AM, Eric W. Biederman <ebiederm@xxxxxxxxxxxx> wrote: > "Michael Kerrisk (man-pages)" <mtk.manpages@xxxxxxxxx> writes: > >> [CC += Lennart] >> >> On Thu, Feb 28, 2013 at 3:24 PM, Vasily Kulikov <segoon@xxxxxxxxxxxx> wrote: >>> Hi Michael, >>> >>> On Thu, Feb 28, 2013 at 12:24 +0100, Michael Kerrisk (man-pages) wrote: >>>> The namespace init process >>>> The first process created in a new namespace (i.e., the process >>>> created using clone(2) with the CLONE_NEWPID flag, or the first >>>> child created by a process after a call to unshare(2) using the >>>> CLONE_NEWPID flag) has the PID 1, and is the "init" process for >>>> the namespace (see init(1)). Children that are orphaned within >>>> the namespace will be reparented to this process rather than >>>> init(1). >>> >>> Probably it worth noting here that this is true unless >>> prctl() with PR_SET_CHILD_SUBREAPER option is called. >> >> Thanks Vasily. It probably is worth mentioning that, and I will add some words. >> >> One thing I am not sure of (have not tested), but maybe you (or Eric) >> know the answer: does the effect of PR_SET_CHILD_SUBREAPER cross a >> PID namespace boundary? > > No. Thanks for the clarification, Eric. I'll note that point in the page. Cheers, Michael >> In other words, if it was a process in the >> parent PID namespace that employed PR_SET_CHILD_SUBREAPER , will that >> affect child processes in a child PID namespace, or wiill >> PR_SET_CHILD_SUBREAPER only apply to child processes in the same PID >> namespace as the caller? > > With respect to reparenting it acts like an additional pid namespace > init is on the path. > > If you want to read the code it is in kernel/exit.c:find_new_reaper(). > called from forget_original_parent, which does the actual reparenting. > > Eric > -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Author of "The Linux Programming Interface"; http://man7.org/tlpi/ -- To unsubscribe from this list: send the line "unsubscribe linux-man" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
