[
https://issues.apache.org/jira/browse/MESOS-5879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15388357#comment-15388357
]
Silas Snider commented on MESOS-5879:
-------------------------------------
We see `Failed to perform recovery: Collect failed: Failed to recover the
net_cls handle for orphan container
60b2c5d274929d4be35c9046d3caa670778a0180a2294c47487718e785812e0c: Failed to
reserve the handle: The secondary handle 0x9, for the primary handle 0x1111 has
already been allocated`.
I'm not sure yet what the root cause is; I filed this JIRA to see if we can
avoid aborting recovery fro unknown orphan containers in the net_cls subsystem
that share already-allocated handles. I totally agree that the actual issue is
some other problem with our environment, I just don't think that preventing the
slave from running in response to this is the right thing.
> 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)
