"Michael Kerrisk (man-pages)" <mtk.manpages@xxxxxxxxx> writes: > Hi Eric, > > On Thu, Feb 28, 2013 at 4:24 PM, Eric W. Biederman > <ebiederm@xxxxxxxxxxxx> wrote: >> "Michael Kerrisk (man-pages)" <mtk.manpages@xxxxxxxxx> writes: > > [...] > >>> ========== >>> PID_NAMESPACES(7) Linux Programmer's Manual PID_NAMESPACES(7) >>> >>> NAME >>> pid_namespaces - overview of Linux PID namespaces >>> >>> DESCRIPTION > [...] > >>> 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). >>> >>> If the "init" process of a PID namespace terminates, the kernel >>> terminates all of the processes in the namespace via a SIGKILL >>> signal. This behavior reflects the fact that the "init" >>> process is essential for the correct operation of a PID names‐ >>> pace. In this case, a subsequent fork(2) into this PID names‐ >>> pace (e.g., from a process that has done a setns(2) into the >>> namespace using an open file descriptor for a >>> /proc/[pid]/ns/pid file corresponding to a process that was in >>> the namespace) will fail with the error ENOMEM; it is not pos‐ >>> sible to create a new processes in a PID namespace whose "init" >>> process has terminated. >> >> It may be useful to mention unshare in the case of fork(2) failing just >> because that is such an easy mistake to make. >> >> unshare(CLONE_NEWPID); >> pid = fork(); >> waitpid(pid,...); >> fork() -> ENOMEM > > I'm lost. Why does that sequence fail? The child of fork() becomes PID > 1 in the new PID namespace. Correct. Then we wait for the child of the fork to exit(); Then we fork again into the new pid namespace. The second fork fails because init has exited. Eric -- 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
