[
https://issues.apache.org/jira/browse/MESOS-6489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15617022#comment-15617022
]
Jie Yu commented on MESOS-6489:
-------------------------------
+1 on moving all destroy logic to Destroyer
1. I suggest we pass a single 'cgroup' to Destroyer as well as TasksKiller and
let them decide how to deal with nested containers. I.e., let them call
cgroups::get(), instead of doing that in top level cgroups::destroy. This
semantics is also pretty clear: destroy this cgroup (or kill all tasks in a
cgroup) for me, no matter if there are nested cgroups or not. More importantly,
this allows us to extend the support to destroy a cgroup if we run docker
daemon inside a container. (i.e., from top down).
2. Destroyer will call TasksKiller first trying to kill all tasks first,
including tasks in nested container. It can recursively instantiate TasksKiller
for nested cgroups. In that way, it can do top down easily. This will be useful
for the daemon in Mesos container case because we no longer need
`continueOnError` if no third party entity is modifying the cgroup from outside.
3. To support you guy's use case, we need to add a hack in 'Destroyer' as you
suggested (continueOnError).
4. then, as YanX suggest, add a repair in caller.
> Better support for containers that want to manage their own cgroup.
> -------------------------------------------------------------------
>
> Key: MESOS-6489
> URL: https://issues.apache.org/jira/browse/MESOS-6489
> Project: Mesos
> Issue Type: Improvement
> Reporter: Jie Yu
>
> Some containers want to manage their cgroup by sub-dividing the cgroup that
> Mesos allocates to them into multiple sub-cgroups and put subprocess into the
> corresponding sub-cgroups.
> For instance, someone wants to run Docker daemon in a Mesos container. Docker
> daemon will manage the cgroup assigned to it by Mesos (with the help , for
> example, cgroups namespace).
> Problems arise during the teardown of the container because two entities
> might be manipulating the same cgroup simultaneously. For example, the Mesos
> cgroups::destroy might fail if the task running inside is trying to delete
> the same nested cgroup at the same time.
> To support that case, we should consider kill all the processes in the Mesos
> cgroup first, making sure that no one will be creating sub-cgroups and moving
> new processes into sub-cgroups. And then, destroy the cgroups recursively.
> And we need freezer because we want to make sure all processes are stopped
> while we are sending kill signals to avoid TOCTTOU race problem. I think it
> makes more sense to freezer the cgroups (and sub-cgroups) from top down
> (rather than bottom up because typically, processes in the parent cgroup
> manipulate sub-cgroups).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
