[
https://issues.apache.org/jira/browse/MESOS-4609?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joseph Wu updated MESOS-4609:
-----------------------------
Description:
Mostly copied from [this
comment|https://issues.apache.org/jira/browse/MESOS-4598?focusedCommentId=15133497&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15133497]
A subprocess inheriting the environment variables {{LIBPROCESS_*}} may run into
some accidental fatalities:
| || Subprocess uses libprocess || Subprocess is something else ||
|| Subprocess sets/inherits the same {{PORT}} by accident | Bind failure -> exit
Option #1 above prevents accidental inheritance | Nothing happens (?) |
|| Subprocess sets a different {{PORT}} on purpose | Bind success (?) | Nothing
happens (?) |
(?) = means this is usually the case, but not 100%.
A complete fix would look something like:
* If the {{subprocess}} call gets {{environment = None()}}, we should
automatically remove {{LIBPROCESS_PORT}} from the inherited environment.
* The parts of
[{{executorEnvironment}}|https://github.com/apache/mesos/blame/master/src/slave/containerizer/containerizer.cpp#L265]
dealing with libprocess & libmesos should be refactored into libprocess as a
helper. We would use this helper for the Containerizer, Fetcher, and
ContainerLogger module.
* If the {{subprocess}} call is given {{LIBPROCESS_PORT ==
os::getenv("LIBPROCESS_PORT")}}, we can LOG(WARN) and unset the env var locally.
was:
The {{LogrotateContainerLogger}} starts libprocess-using subprocesses.
Libprocess initialization will attempt to resolve the IP from the hostname. If
a DNS service is not available, this step will fail, which terminates the
logger subprocess prematurely.
Since the logger subprocesses live on the agent, they should use the same
{{LIBPROCESS_IP}} supplied to the agent.
> Subprocess should be more intelligent about setting/inheriting libprocess
> environment variables
> ------------------------------------------------------------------------------------------------
>
> Key: MESOS-4609
> URL: https://issues.apache.org/jira/browse/MESOS-4609
> Project: Mesos
> Issue Type: Bug
> Affects Versions: 0.27.0
> Reporter: Joseph Wu
> Assignee: Joseph Wu
> Labels: mesosphere
>
> Mostly copied from [this
> comment|https://issues.apache.org/jira/browse/MESOS-4598?focusedCommentId=15133497&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15133497]
> A subprocess inheriting the environment variables {{LIBPROCESS_*}} may run
> into some accidental fatalities:
> | || Subprocess uses libprocess || Subprocess is something else ||
> || Subprocess sets/inherits the same {{PORT}} by accident | Bind failure ->
> exit
> Option #1 above prevents accidental inheritance | Nothing happens (?) |
> || Subprocess sets a different {{PORT}} on purpose | Bind success (?) |
> Nothing happens (?) |
> (?) = means this is usually the case, but not 100%.
> A complete fix would look something like:
> * If the {{subprocess}} call gets {{environment = None()}}, we should
> automatically remove {{LIBPROCESS_PORT}} from the inherited environment.
> * The parts of
> [{{executorEnvironment}}|https://github.com/apache/mesos/blame/master/src/slave/containerizer/containerizer.cpp#L265]
> dealing with libprocess & libmesos should be refactored into libprocess as a
> helper. We would use this helper for the Containerizer, Fetcher, and
> ContainerLogger module.
> * If the {{subprocess}} call is given {{LIBPROCESS_PORT ==
> os::getenv("LIBPROCESS_PORT")}}, we can LOG(WARN) and unset the env var
> locally.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
