Re: [PATCH 0/15] Add preliminary support for Linux containers

[Ludovic Courtès]

"Thompson, David" <address@hidden> skribis:

> On Wed, Jul 8, 2015 at 8:46 AM, Ludovic Courtès <address@hidden> wrote:
>> "Thompson, David" <address@hidden> skribis:
>>
>>> On Tue, Jul 7, 2015 at 6:28 AM, Ludovic Courtès <address@hidden> 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’.