You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mesos.apache.org by "Ian Downes (JIRA)" <ji...@apache.org> on 2014/03/14 19:32:43 UTC

[jira] [Comment Edited] (MESOS-1094) Introduce pid namespace abstraction to subprocess

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

Ian Downes edited comment on MESOS-1094 at 3/14/14 6:31 PM:
------------------------------------------------------------

Let me sketch out my thoughts now ;-)

Given concerns about async signal safety I'd like to use an external binary to do namespace operations rather than an abstraction in stout. This would be called something like mesos-nsexec and it would exec the process after doing clone() or unshare() appropriately. This means that Subprocess doesn't change and we just modify the command (perhaps the abstraction happens here so the prefixing is transparent), e.g., to "mesos-nsexec --pid /path/to/command" to run the command in a pid namespace.

mesos-nsexec would be generally useful for running processes inside any namespace and also for running processes inside existing namespaces, specified by either a pid already in the desired namespace or a path to a ns file descriptor (bind mounted from proc).

How does this sound?



was (Author: idownes):
Let me sketch out my thoughts now ;-)

Given concerns about async signal safety I'd like to use an external binary to do namespace operations rather than an abstraction in stout. This would be called something like mesos-nsexec and it would exec the process after doing clone() or unshare() appropriately. This means that Subprocess doesn't change and we just modify the command (perhaps the abstraction happens here so the prefixing is transparent), e.g., to "mesos-nsexec --pid /path/to/command" to run the command in a pid namespace.

mesos-nsexec would be generally useful for running processes inside any namespace and also for running processes inside existing namespaces, specified by either a pid already in the desired namespace or a path to a ns file descriptor (bind mounted from /proc/{pid}/ns/*).

How does this 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)