mesos-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Niklas Quarfot Nielsen (JIRA)" <>
Subject [jira] [Commented] (MESOS-1094) Introduce pid namespace abstraction to subprocess
Date Fri, 14 Mar 2014 18:10:44 GMT


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:
>             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

This message was sent by Atlassian JIRA

View raw message