|
|
Subscribe / Log in / New account

Namespaces in operation, part 4: more on PID namespaces

Namespaces in operation, part 4: more on PID namespaces

Posted Feb 13, 2019 10:02 UTC (Wed) by mkerrisk (subscriber, #1978)
In reply to: Namespaces in operation, part 4: more on PID namespaces by ywchang
Parent article: Namespaces in operation, part 4: more on PID namespaces

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.


(Log in to post comments)

Namespaces in operation, part 4: more on PID namespaces

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

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]

> 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!


Copyright © 2023, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds