From: ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org (Eric W. Biederman)
To: mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
Cc: linux-man <linux-man-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
Linux Containers
<containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org>,
lkml <linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Subject: Re: For review: pid_namespaces(7) man page
Date: Fri, 01 Mar 2013 01:10:23 -0800 [thread overview]
Message-ID: <877glr5vuo.fsf@xmission.com> (raw)
In-Reply-To: <CAKgNAkjxrbcpONCU4UdD0-cjXwbHr+YwkOR0H_aXp3CGB283Uw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> (Michael Kerrisk's message of "Fri, 1 Mar 2013 09:50:16 +0100")
"Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com> writes:
> Hi Eric,
>
> On Thu, Feb 28, 2013 at 4:24 PM, Eric W. Biederman
> <ebiederm@xmission.com> wrote:
>> "Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com> 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
_______________________________________________
Containers mailing list
Containers@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/containers
WARNING: multiple messages have this Message-ID (diff)
From: ebiederm@xmission.com (Eric W. Biederman)
To: mtk.manpages@gmail.com
Cc: Linux Containers <containers@lists.linux-foundation.org>,
"Serge E. Hallyn" <serge@hallyn.com>,
lkml <linux-kernel@vger.kernel.org>,
linux-man <linux-man@vger.kernel.org>
Subject: Re: For review: pid_namespaces(7) man page
Date: Fri, 01 Mar 2013 01:10:23 -0800 [thread overview]
Message-ID: <877glr5vuo.fsf@xmission.com> (raw)
In-Reply-To: <CAKgNAkjxrbcpONCU4UdD0-cjXwbHr+YwkOR0H_aXp3CGB283Uw@mail.gmail.com> (Michael Kerrisk's message of "Fri, 1 Mar 2013 09:50:16 +0100")
"Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com> writes:
> Hi Eric,
>
> On Thu, Feb 28, 2013 at 4:24 PM, Eric W. Biederman
> <ebiederm@xmission.com> wrote:
>> "Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com> 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
next prev parent reply other threads:[~2013-03-01 9:10 UTC|newest]
Thread overview: 79+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-02-28 11:24 For review: pid_namespaces(7) man page Michael Kerrisk (man-pages)
2013-02-28 11:24 ` Michael Kerrisk (man-pages)
[not found] ` <CAKgNAki=mUYuu_Ewhe7sjCmo+Dq2Vr+FZCixqNRaadcvAxtpFw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2013-02-28 14:24 ` Vasily Kulikov
2013-02-28 14:24 ` Vasily Kulikov
2013-03-01 8:03 ` Michael Kerrisk (man-pages)
2013-03-01 8:03 ` Michael Kerrisk (man-pages)
[not found] ` <CAKgNAkjXAfq4RwtX1ELier+GLv0D5e9spM3Os3-oqSCXGqRqOg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2013-03-01 8:36 ` Eric W. Biederman
2013-03-01 8:36 ` Eric W. Biederman
2013-03-01 8:36 ` Eric W. Biederman
[not found] ` <87fw0f5xfw.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
2013-03-01 8:53 ` Michael Kerrisk (man-pages)
2013-03-01 8:53 ` Michael Kerrisk (man-pages)
2013-02-28 14:24 ` Vasily Kulikov
2013-02-28 15:24 ` Eric W. Biederman
2013-02-28 15:24 ` Eric W. Biederman
[not found] ` <87txowa2cm.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
2013-03-01 8:50 ` Michael Kerrisk (man-pages)
2013-03-01 8:50 ` Michael Kerrisk (man-pages)
[not found] ` <CAKgNAkjxrbcpONCU4UdD0-cjXwbHr+YwkOR0H_aXp3CGB283Uw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2013-03-01 9:10 ` Eric W. Biederman [this message]
2013-03-01 9:10 ` Eric W. Biederman
[not found] ` <877glr5vuo.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
2013-03-01 10:20 ` Michael Kerrisk (man-pages)
2013-03-01 10:20 ` Michael Kerrisk (man-pages)
2013-03-01 10:20 ` Michael Kerrisk (man-pages)
2013-03-01 8:50 ` Michael Kerrisk (man-pages)
2013-02-28 15:24 ` Eric W. Biederman
2013-03-01 4:01 ` Rob Landley
2013-03-01 4:01 ` Rob Landley
2013-03-01 6:58 ` Eric W. Biederman
2013-03-01 6:58 ` Eric W. Biederman
2013-03-01 6:58 ` Eric W. Biederman
2013-03-01 9:57 ` Michael Kerrisk (man-pages)
2013-03-01 9:57 ` Michael Kerrisk (man-pages)
[not found] ` <CAKgNAkgVKnhRT1Lpq4a_UdBKB+tn6XmWSDF2QJXG0aSLtNH6dg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2013-03-01 15:35 ` Eric W. Biederman
2013-03-01 15:35 ` Eric W. Biederman
[not found] ` <87wqtr3zg5.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
2013-03-04 12:46 ` Michael Kerrisk (man-pages)
2013-03-04 12:46 ` Michael Kerrisk (man-pages)
[not found] ` <CAKgNAkjGD0FdQqpA+rYR=+Yc5uVPB8mE5JjCqy-5WS85cPsvng-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2013-03-04 17:52 ` Eric W. Biederman
2013-03-04 17:52 ` Eric W. Biederman
[not found] ` <87k3pnhx2k.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
2013-03-05 5:30 ` Michael Kerrisk (man-pages)
[not found] ` <CAKgNAkjYmvjMzC+nYqsjHf4bQn2ZwdE5wawoP2p32ZSo+0dfcQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2013-03-05 6:23 ` Michael Kerrisk (man-pages)
2013-03-05 6:23 ` Michael Kerrisk (man-pages)
2013-03-05 6:23 ` Michael Kerrisk (man-pages)
2013-03-05 6:41 ` Eric W. Biederman
2013-03-05 6:41 ` Eric W. Biederman
[not found] ` <87r4jucprp.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
2013-03-05 8:37 ` Michael Kerrisk (man-pages)
2013-03-05 8:37 ` Michael Kerrisk (man-pages)
2013-03-05 8:37 ` Michael Kerrisk (man-pages)
[not found] ` <CAKgNAkgqE7owqsmD+9-9fZtzMQ76H53a+Aat0CH670jNTUfbFA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2013-03-06 0:40 ` Eric W. Biederman
2013-03-06 0:40 ` Eric W. Biederman
[not found] ` <87boax4axy.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
2013-03-07 8:20 ` Michael Kerrisk (man-pages)
2013-03-07 8:20 ` Michael Kerrisk (man-pages)
[not found] ` <CAKgNAkgRs7kg5PsMrBDNO8_z=5L5zM7DmLgU8pNwT_ck4Hmvhw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2013-03-07 8:31 ` Eric W. Biederman
2013-03-07 8:31 ` Eric W. Biederman
2013-03-07 8:31 ` Eric W. Biederman
2013-03-06 0:40 ` Eric W. Biederman
2013-03-05 6:41 ` Eric W. Biederman
2013-03-06 1:58 ` Rob Landley
2013-03-06 1:58 ` Rob Landley
2013-03-06 2:23 ` Eric W. Biederman
2013-03-06 2:23 ` Eric W. Biederman
2013-03-04 12:46 ` Michael Kerrisk (man-pages)
2013-03-01 15:35 ` Eric W. Biederman
2013-03-04 3:50 ` Rob Landley
2013-03-04 3:50 ` Rob Landley
2013-03-04 4:03 ` Eric W. Biederman
2013-03-04 4:03 ` Eric W. Biederman
[not found] ` <876217olp0.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
2013-03-04 12:48 ` Michael Kerrisk (man-pages)
2013-03-04 12:48 ` Michael Kerrisk (man-pages)
2013-03-04 12:48 ` Michael Kerrisk (man-pages)
2013-03-04 19:27 ` Rob Landley
2013-03-04 19:27 ` Rob Landley
2013-03-05 7:01 ` Michael Kerrisk (man-pages)
2013-03-05 7:01 ` Michael Kerrisk (man-pages)
2013-03-05 7:01 ` Michael Kerrisk (man-pages)
2013-03-04 12:50 ` Michael Kerrisk (man-pages)
2013-03-04 12:50 ` Michael Kerrisk (man-pages)
2013-03-04 12:50 ` Michael Kerrisk (man-pages)
-- strict thread matches above, loose matches on Subject: below --
2013-02-28 11:24 Michael Kerrisk (man-pages)
2014-08-20 23:38 Michael Kerrisk (man-pages)
2014-08-20 23:38 ` Michael Kerrisk (man-pages)
2014-08-20 23:38 ` Michael Kerrisk (man-pages)
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=877glr5vuo.fsf@xmission.com \
--to=ebiederm-as9lmozglivwk0htik3j/w@public.gmane.org \
--cc=containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-man-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.