[
https://issues.apache.org/jira/browse/MESOS-1094?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13935404#comment-13935404
]
Ian Downes commented on MESOS-1094:
-----------------------------------
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)
