Namespaces in operation, part 4: more on PID namespaces [LWN.net]

Namespaces in operation, part 4: more on PID namespaces

Posted Feb 12, 2019 6:30 UTC (Tue) by ywchang (guest, #130070)
Parent article: Namespaces in operation, part 4: more on PID namespaces

I can get expected results from codes and commands covered in the post.

However, for the last part, I am thinking, it probably also should work if there is no `-f` option for the `ns_run` command.

If there is no `-f`, that means, the `ns_run` process itself will first update pid namespace, and then run the `./orphan` itself. Then the forked child will show up in the new pid namespace, while `ns_run` will die. The forked child process should also be reaped by the init process in the new pid namespace, right?

I tried and it didn't work as I described. Anyone shed some light please? Thanks in advance.

to post comments

Namespaces in operation, part 4: more on PID namespaces

Posted Feb 13, 2019 10:02 UTC (Wed) by mkerrisk (subscriber, #1978) [Link] (3 responses)

As described in the article, the setns() and unshare() system calls treat PID namespaces specially. For other types of namespaces, these system calls do change the namespace of the caller. For PID namespaces, these system calls do not change the PID namespace of the calling process. Instead, any subsequently created children of the caller will be created in the target/new namespace.

If the -f option was omitted, the ns_run command would execute the orphan program in the PID namespace where ns_run resides, rather than the namespace specified by the -n option.

Namespaces in operation, part 4: more on PID namespaces

Posted Feb 14, 2019 9:58 UTC (Thu) by ywchang (guest, #130070) [Link] (2 responses)

Thanks so much for your reply.

I get your point that PID namespace is special, that using `setns()` the calling process itself will not join the new namespace, while the children forked will be joining the new namespace.

I raised the question that if we can drop the `-f`, is because if looking at the implementation of `orphan` codes, the orphan process is actually forked out from the `ns_run`, which has called `setns()` before. That means if `ns_run` serve as the parent, fork the orphan, and then exit. Then the orphan process should in theory be in the new namespace.

I did the experiment, drop the `-f` option, and then I found the orphan did show up in the new namespace. Because I use the readlink against the orphan process outside PID namespace, same with PID namespace `init` process.

I mounted the proc to /proc2, and run `ls -d /proc2/[1-9]*`

The results is like

/proc2/1 /proc2/2

And I run this command to explore /proc2/2, `cat /proc2/2/status | egrep '^(Name|PP*id)'`

it shows me this,

Name: orphan
Pid: 2
PPid: 0

At this moment, I'm confused. Why the orphan process is not reaped by `init` process? And why the PPid is becoming 0?

Namespaces in operation, part 4: more on PID namespaces

Posted Feb 15, 2019 7:59 UTC (Fri) by mkerrisk (subscriber, #1978) [Link] (1 responses)

> Why the orphan process is not reaped by `init` process?
> And why the PPid is becoming 0?

When a process becomes orphaned it is reparented to the init process *in the PID namespace of its parent*.

When you run the 'orphan' program without the '-f' option, then the child is in the new PID namespace, but its parent is still in the initial PID NS. Thus the orphan gets reparented to init in the initial PID namespace.

PPid == 0 is the system's way of telling the child process that it has no visible parent (because the parent is in another PID namespace).

Namespaces in operation, part 4: more on PID namespaces

Posted Feb 16, 2019 7:04 UTC (Sat) by ywchang (guest, #130070) [Link]

This clears my doubt! Thanks so much for your explanation!