[
https://issues.apache.org/jira/browse/MESOS-1094?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13938487#comment-13938487
]
Ian Downes commented on MESOS-1094:
-----------------------------------
I started on this last week and ran into a slight complication specific to pid
namespaces: mesos-nsexec (as a Subprocess) would need to clone() another child
to get it into a pid namespace. What I'm working on now is to indeed add
support for creating pid namespaces to Subprocess but leave other namespace
operations (including entering an existing pid namespace) to mesos-nsexec.
I'll work on the Subprocess support shortly.
> Introduce pid namespace abstraction to subprocess
> -------------------------------------------------
>
> Key: MESOS-1094
> URL: https://issues.apache.org/jira/browse/MESOS-1094
> Project: Mesos
> Issue Type: Improvement
> Reporter: Niklas Quarfot Nielsen
> Assignee: Niklas Quarfot Nielsen
>
> Introducing PID namespacing could simplify signal escalation and process
> control in for example the command executor and pluggable containerizer.
> Along the lines of the Fork Exec abstraction in stout, I suggest that we add
> an abstraction for Linux namespaces.
> LinuxNamespace(PID /* | IPC | mount | ...*/, Fork(Exec("sleep 10"))
> It would be guarded or add convenience methods to ensure system support, for
> example bool LinuxNamespace::supports(PID /* | IPC | ... */) or simply let
> the namespace fall back to regular fork/exec.
> I have a proof-of-concept version of the command executor which use PID
> namespaces (in combination with delay/escalation), and it feels like details
> around stack allocation and management could be captured in a new abstraction
> and make it a neat and nice subsystem to use.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
