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

Avinash Sridharan edited comment on MESOS-5879 at 7/23/16 4:20 PM:
-------------------------------------------------------------------

Ah makes sense. We can use this JIRA itself to track the issue. I think the 
current expectation was that cgroups (for each container) are created only by 
Mesos. Can you clarify as to why you need to create new cgroups for your 
containers that are going to use the same `net_cls` class handles? If they are 
child containers they will automatically be reflected in the `processes` of 
that specific cgroup and inherit the handles. 

 [~jieyu] does Mesos support semantics where multiple isolators are modifying 
the same cgroups hierarchy? 


was (Author: [email protected]):
Ah makes sense. We can use this JIRA itself to track the issue. I think the 
current expectation was that cgroups (for each container) are created only by 
Mesos. 

> cgroups/net_cls isolator causing agent recovery issues
> ------------------------------------------------------
>
>                 Key: MESOS-5879
>                 URL: https://issues.apache.org/jira/browse/MESOS-5879
>             Project: Mesos
>          Issue Type: Bug
>          Components: cgroups, isolation, slave
>            Reporter: Silas Snider
>            Assignee: Avinash Sridharan
>
> We run with 'cgroups/net_cls' in our isolator list, and when we restart any 
> agent process in a cluster running an experimental custom isolator as well, 
> the agents are unable to recover from checkpoint, because net_cls reports 
> that unknown orphan containers have duplicate net_cls handles.
> While this is a problem that needs to be solved (probably by fixing our 
> custom isolator), it's also a problem that the net_cls isolator fails 
> recovery just for duplicate handles in cgroups that it is literally about to 
> unconditionally destroy during recovery. Can this be fixed?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to