You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@mesos.apache.org by "Anindya Sinha (JIRA)" <ji...@apache.org> on 2016/11/02 04:45:58 UTC
[jira] [Assigned] (MESOS-6489) Better support for containers that
want to manage their own cgroup.
[ https://issues.apache.org/jira/browse/MESOS-6489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Anindya Sinha reassigned MESOS-6489:
------------------------------------
Assignee: Anindya Sinha
> 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
> Components: cgroups
> Reporter: Jie Yu
> Assignee: Anindya Sinha
> Labels: cgroups
>
> 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)