[
https://issues.apache.org/jira/browse/MESOS-1094?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13935365#comment-13935365
]
Niklas Quarfot Nielsen commented on MESOS-1094:
-----------------------------------------------
Feel free; let's stay in touch though. I was assigning myself as I thought it
as a requirement for signal escalation (which blocks Jasons work on pluggable
containerization). I chatted with BenH and will do a first pass with signal
escalation that doesn't capture orphan processes (delay + repeated killtree)
and when you have the pid namespace abstraction working; wire that up in the
command executor. How does that sound?
> 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)
