[ 
https://issues.apache.org/jira/browse/MESOS-9116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16586276#comment-16586276
 ] 

Alexander Rukletsov commented on MESOS-9116:
--------------------------------------------

Backports to 1.6.x:
{noformat}
cfba574408a85861d424a2c58d3d7277490c398e
6d884fbf9be169fd97483a1f341540c5354d88a9
a4409826deada53eef8843df1a0178e9edfa4c9c
20a4d4fae2f30f9e5436a154087c1a1bb9dc0629
{noformat}
Backports to 1.5.x:
{noformat}
6dd3fcc8ab2aecd182fff29deac07b32b3cc2d81
edeac7b0da5dd7ee1e4e50320d964eb84220d87d
966574a31a3f8c5d4f9a5f02eeb1644aff7fdc97
e4d8ab9911af6d494aae7f5762dd84b8f085fd1e
{noformat}

> Launch nested container session fails due to incorrect detection of `mnt` 
> namespace of command executor's task.
> ---------------------------------------------------------------------------------------------------------------
>
>                 Key: MESOS-9116
>                 URL: https://issues.apache.org/jira/browse/MESOS-9116
>             Project: Mesos
>          Issue Type: Bug
>          Components: agent, containerization
>            Reporter: Andrei Budnik
>            Assignee: Andrei Budnik
>            Priority: Critical
>              Labels: mesosphere
>             Fix For: 1.7.0
>
>         Attachments: pstree.png
>
>
> Launch nested container call might fail with the following error:
> {code:java}
> Failed to enter mount namespace: Failed to open '/proc/29473/ns/mnt': No such 
> file or directory
> {code}
> This happens when the containerizer launcher [tries to 
> enter|https://github.com/apache/mesos/blob/077f122d52671412a2ab5d992d535712cc154002/src/slave/containerizer/mesos/launch.cpp#L879-L892]
>  `mnt` namespace using the pid of a terminated process. The pid [was 
> detected|https://github.com/apache/mesos/blob/077f122d52671412a2ab5d992d535712cc154002/src/slave/containerizer/mesos/containerizer.cpp#L1930-L1958]
>  by the agent before spawning the containerizer launcher process, because the 
> process was running back then.
> The issue can be reproduced using the following test (pseudocode):
> {code:java}
> launchTask("sleep 1000")
> parentContainerId = containerizer.containers().begin()
> outputs = []
> for i in range(10):
>   ContainerId containerId
>   containerId.parent = parentContainerId
>   containerId.id = UUID.random()
>   LAUNCH_NESTED_CONTAINER_SESSION(containerId, "echo echo")
>   response = ATTACH_CONTAINER_OUTPUT(containerId)
>   outputs.append(response.reader)
> for output in outputs:
>   stdout, stderr = getProcessIOData(output)
>   assert("echo" == stdout + stderr){code}
> When we start the very first nested container, `getMountNamespaceTarget()` 
> returns a PID of the task (`sleep 1000`), because it's the only process whose 
> `mnt` namespace differs from the parent container. This nested container 
> becomes a child of PID 1 process, which is also a parent of the command 
> executor. It's not an executor's child! It can be seen in attached 
> `pstree.png`.
> When we start a second nested container, `getMountNamespaceTarget()` might 
> return PID of the previous nested container (`echo echo`) instead of the 
> task's PID (`sleep 1000`). It happens because the first nested container 
> entered `mnt` namespace of the task. Then, the containerizer launcher 
> ("nanny" process) attempts to enter `mnt` namespace using the PID of a 
> terminated process, so we get this error.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Reply via email to