"Thompson, David" <dthomps...@worcester.edu> skribis: > On Wed, Jul 8, 2015 at 8:46 AM, Ludovic Courtès <l...@gnu.org> wrote: >> "Thompson, David" <dthomps...@worcester.edu> skribis: >> >>> On Tue, Jul 7, 2015 at 6:28 AM, Ludovic Courtès <l...@gnu.org> wrote: >> >> [...] >> >>>>> (lambda () >>>>> (sethostname "guix-0.8.3")) >>>> >>>> Surprisingly, calling ‘getpid’ in the thunk returns the PID of the >>>> parent (I was expecting it to return 1.) Not sure why that is the >>>> case. I’m still amazed that this works as non-root, BTW. >>> >>> The first process created inside the PID namespace gets the honor of >>> being PID 1, not the process created with the 'clone' call. >>> >>> For more information, see: https://lwn.net/Articles/532748/ >> >> To me, the thunk above is just like ‘childFunc’ in >> <https://lwn.net/Articles/533492/>–i.e., it’s the procedure that ‘clone’ >> calls in the first child process of the new PID name space. >> >> What am I missing? > > It's non-intuitive because PID namespaces are given special treatment. > The cloned process is like PID 1 in the sense that if you fork, the > new process is PID 2. However, if you call 'getpid' in the cloned > process, it returns the PID in the context of the parent PID > namespace, and you are expecting PID 1. > > In that example from LWN, 'childFunc' calls 'execvp', and *that* new > process becomes PID 1 (and 'getpid' agrees). This is the usual > pattern I see in all container implementations: The process that > calls clone sets up the environment and then execs the real init > system. > > Is it more clear now?
Yes, indeed. The weird part is that ‘exec’ does not create a new process, so it’s not supposed to change the return value of ‘getpid’. But I guess it’s just an artifact of the whole name space hack. ;-) Thanks! Ludo’.
