[
https://issues.apache.org/jira/browse/MESOS-9116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16581263#comment-16581263
]
Andrei Budnik edited comment on MESOS-9116 at 8/16/18 2:50 PM:
---------------------------------------------------------------
We should call
`[getMountNamespaceTarget()`|https://github.com/apache/mesos/blob/077f122d52671412a2ab5d992d535712cc154002/src/slave/containerizer/mesos/utils.cpp#L59]
only in case of command executor, otherwise it might detect incorrect `mnt`
namespace. We have found one such case:
A framework launches a task A without executor. This task A launches another
subtask B which calls
[`unshare`|http://man7.org/linux/man-pages/man1/unshare.1.html] to unshare
mount namespace from its parent A. The process tree will look like:
{code:java}
0. root (mesos-containerizer) [root `mnt` namespace]
1. task A [root `mnt` namespace]
2. subtask B [subtask's `mnt` namespace]
{code}
When the framework launches nested container session via `LNCS` API, mesos
c'zer calls `getMountNamespaceTarget()`, which returns PID of subtask B. Hence,
the nested container will attempt to enter subtasks's `mnt` namespace instead
of task's `mnt` namespace.
It would be great to cover this case with tests.
was (Author: abudnik):
We should call
`[getMountNamespaceTarget()`|https://github.com/apache/mesos/blob/077f122d52671412a2ab5d992d535712cc154002/src/slave/containerizer/mesos/utils.cpp#L59]
only in case of command executor, otherwise it might detect incorrect `mnt`
namespace. We have found two such cases:
1) The default executor launches a task A via `LNC` call. The process tree will
look like:
{code:java}
0. root (mesos-containerizer) [root `mnt` namespace]
1. default-executor [root `mnt` namespace]
1. nanny (mesos-containerizer) [task's `mnt` namespace]
2. cat [task's `mnt` namespace]{code}
When the framework launches nested container session via `LNCS` API, mesos
c'zer calls `getMountNamespaceTarget()`, which doesn't find any candidate.
`getMountNamespaceTarget()` returns PID of the candidate when `mnt` namespace
of 0- and 1- level processes are equal, while 2-nd level process is running in
its own `mnt` namespace. This condition is not satisfied in this case, so
`getMountNamespaceTarget()` cannot detect task's `mnt` namespace.
2) A framework launches a task A without executor. This task A launches another
subtask B which calls
[`unshare`|http://man7.org/linux/man-pages/man1/unshare.1.html] to unshare
mount namespace from its parent A. The process tree will look like:
{code:java}
0. root (mesos-containerizer) [root `mnt` namespace]
1. task A [root `mnt` namespace]
2. subtask B [subtask's `mnt` namespace]
{code}
When the framework launches nested container session via `LNCS` API, mesos
c'zer calls `getMountNamespaceTarget()`, which returns PID of subtask B. Hence,
the nested container will attempt to enter subtasks's `mnt` namespace instead
of task's `mnt` namespace.
It would be great to cover these cases with tests.
> 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
> 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)
