[jira] [Commented] (MESOS-6240) Allow executor/agent communication over non-TCP/IP stream socket.
[ https://issues.apache.org/jira/browse/MESOS-6240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16191759#comment-16191759 ] Aaron Wood commented on MESOS-6240: --- +1 to what [~zhitao] said! > Allow executor/agent communication over non-TCP/IP stream socket. > - > > Key: MESOS-6240 > URL: https://issues.apache.org/jira/browse/MESOS-6240 > Project: Mesos > Issue Type: Improvement > Components: containerization > Environment: Linux and Windows >Reporter: Avinash Sridharan >Assignee: Benjamin Hindman >Priority: Critical > Labels: mesosphere > > Currently, the executor agent communication happens specifically over TCP > sockets. This works fine in most cases, but specifically for the > `MesosContainerizer` when containers are running on CNI networks, this mode > of communication starts imposing constraints on the CNI network. Since, now > there has to connectivity between the CNI network (on which the executor is > running) and the agent. Introducing paths from a CNI network to the > underlying agent, at best, creates headaches for operators and at worst > introduces serious security holes in the network, since it is breaking the > isolation between the container CNI network and the host network (on which > the agent is running). > In order to simplify/strengthen deployment of Mesos containers on CNI > networks we therefore need to move away from using TCP/IP sockets for > executor/agent communication. Since, executor and agent are guaranteed to run > on the same host, the above problems can be resolved if, for the > `MesosContainerizer`, we use UNIX domain sockets or named pipes instead of > TCP/IP sockets for the executor/agent communication. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (MESOS-4969) improve overlayfs detection
[
https://issues.apache.org/jira/browse/MESOS-4969?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16122375#comment-16122375
]
Aaron Wood edited comment on MESOS-4969 at 8/10/17 9:34 PM:
Sorry, I thought Mesos was only looking at {{/proc/modules}}.
was (Author: aaron.wood):
Sorry, I thought Mesos was only looking at {noformat}/proc/modules{noformat}.
> improve overlayfs detection
> ---
>
> Key: MESOS-4969
> URL: https://issues.apache.org/jira/browse/MESOS-4969
> Project: Mesos
> Issue Type: Bug
> Components: containerization, storage
>Reporter: James Peach
>Priority: Minor
>
> On my Fedora 23, overlayfs is a module that is not loaded by default
> (attempting to mount an overlayfs automatically triggers the module loading).
> However {{mesos-slave}} won't start until I manually load the module since it
> is not listed in {{/proc/filesystems}} until is it loaded.
> It would be nice if there was a more reliable way to determine overlayfs
> support.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MESOS-4969) improve overlayfs detection
[
https://issues.apache.org/jira/browse/MESOS-4969?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16122375#comment-16122375
]
Aaron Wood commented on MESOS-4969:
---
Sorry, I thought Mesos was only looking at {noformat}/proc/modules{noformat}.
> improve overlayfs detection
> ---
>
> Key: MESOS-4969
> URL: https://issues.apache.org/jira/browse/MESOS-4969
> Project: Mesos
> Issue Type: Bug
> Components: containerization, storage
>Reporter: James Peach
>Priority: Minor
>
> On my Fedora 23, overlayfs is a module that is not loaded by default
> (attempting to mount an overlayfs automatically triggers the module loading).
> However {{mesos-slave}} won't start until I manually load the module since it
> is not listed in {{/proc/filesystems}} until is it loaded.
> It would be nice if there was a more reliable way to determine overlayfs
> support.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MESOS-4969) improve overlayfs detection
[
https://issues.apache.org/jira/browse/MESOS-4969?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16120586#comment-16120586
]
Aaron Wood commented on MESOS-4969:
---
Another thought, we are building/using our own kernel for our nodes which will
have this module built in. Doesn't that mean this /proc check will fail?
> improve overlayfs detection
> ---
>
> Key: MESOS-4969
> URL: https://issues.apache.org/jira/browse/MESOS-4969
> Project: Mesos
> Issue Type: Bug
> Components: containerization, storage
>Reporter: James Peach
>Priority: Minor
>
> On my Fedora 23, overlayfs is a module that is not loaded by default
> (attempting to mount an overlayfs automatically triggers the module loading).
> However {{mesos-slave}} won't start until I manually load the module since it
> is not listed in {{/proc/filesystems}} until is it loaded.
> It would be nice if there was a more reliable way to determine overlayfs
> support.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MESOS-4969) improve overlayfs detection
[
https://issues.apache.org/jira/browse/MESOS-4969?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16120582#comment-16120582
]
Aaron Wood commented on MESOS-4969:
---
Why not let the OS load it on demand when needed instead of prematurely
checking and failing right away? That way no one needs to explicitly enable the
module and add it to /etc/modules.
> improve overlayfs detection
> ---
>
> Key: MESOS-4969
> URL: https://issues.apache.org/jira/browse/MESOS-4969
> Project: Mesos
> Issue Type: Bug
> Components: containerization, storage
>Reporter: James Peach
>Priority: Minor
>
> On my Fedora 23, overlayfs is a module that is not loaded by default
> (attempting to mount an overlayfs automatically triggers the module loading).
> However {{mesos-slave}} won't start until I manually load the module since it
> is not listed in {{/proc/filesystems}} until is it loaded.
> It would be nice if there was a more reliable way to determine overlayfs
> support.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (MESOS-7768) Implement permissions handling
Aaron Wood created MESOS-7768: - Summary: Implement permissions handling Key: MESOS-7768 URL: https://issues.apache.org/jira/browse/MESOS-7768 Project: Mesos Issue Type: Task Components: stout Reporter: Aaron Wood Working with permissions on Windows seems to be unresolved at the moment. This needs to be implemented to allow for various code in stout to work in a cross-platform way. This https://github.com/apache/mesos/commit/6271682e67e0afa4c2d9395f7296e3bebbe909ff is one example where an ifndef is required due to os::which working with permissions underneath. There is a current effort to move permissions.hpp under posix/ but that brought up the issue of the header being included from sources that are cross-platform https://reviews.apache.org/r/60693/ -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (MESOS-7764) Move permissions.hpp under posix
[ https://issues.apache.org/jira/browse/MESOS-7764?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aaron Wood updated MESOS-7764: -- Summary: Move permissions.hpp under posix (was: Move permissions.hpp under posix in stout) > Move permissions.hpp under posix > > > Key: MESOS-7764 > URL: https://issues.apache.org/jira/browse/MESOS-7764 > Project: Mesos > Issue Type: Task > Components: stout >Reporter: Aaron Wood >Assignee: Aaron Wood > > The way permissions are dealt with in this file are not cross compatible with > Windows. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (MESOS-7764) Move permissions.hpp under posix in stout
Aaron Wood created MESOS-7764: - Summary: Move permissions.hpp under posix in stout Key: MESOS-7764 URL: https://issues.apache.org/jira/browse/MESOS-7764 Project: Mesos Issue Type: Task Components: stout Reporter: Aaron Wood Assignee: Aaron Wood The way permissions are dealt with in this file are not cross compatible with Windows. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (MESOS-7737) Harden Mesos when building with cmake
[ https://issues.apache.org/jira/browse/MESOS-7737?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aaron Wood updated MESOS-7737: -- Shepherd: Joseph Wu > Harden Mesos when building with cmake > - > > Key: MESOS-7737 > URL: https://issues.apache.org/jira/browse/MESOS-7737 > Project: Mesos > Issue Type: Improvement > Components: cmake >Reporter: Aaron Wood >Assignee: Aaron Wood >Priority: Minor > > Apply stack protectors (stronger stack protectors with newer compilers), > position independent code suitable for linking into executables, security > warnings, and generate position independent executables. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MESOS-7737) Harden Mesos when building with cmake
[ https://issues.apache.org/jira/browse/MESOS-7737?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16068732#comment-16068732 ] Aaron Wood commented on MESOS-7737: --- https://reviews.apache.org/r/60546/ > Harden Mesos when building with cmake > - > > Key: MESOS-7737 > URL: https://issues.apache.org/jira/browse/MESOS-7737 > Project: Mesos > Issue Type: Improvement > Components: cmake >Reporter: Aaron Wood >Assignee: Aaron Wood >Priority: Minor > > Apply stack protectors (stronger stack protectors with newer compilers), > position independent code suitable for linking into executables, security > warnings, and generate position independent executables. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (MESOS-7737) Harden Mesos when building with cmake
[ https://issues.apache.org/jira/browse/MESOS-7737?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aaron Wood updated MESOS-7737: -- Summary: Harden Mesos when building with cmake (was: Provide a more secure cmake build) > Harden Mesos when building with cmake > - > > Key: MESOS-7737 > URL: https://issues.apache.org/jira/browse/MESOS-7737 > Project: Mesos > Issue Type: Improvement > Components: cmake >Reporter: Aaron Wood >Assignee: Aaron Wood >Priority: Minor > > Apply stack protectors (stronger stack protectors with newer compilers), > position independent code suitable for linking into executables, security > warnings, and generate position independent executables. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (MESOS-7737) Provide a more secure cmake build
Aaron Wood created MESOS-7737: - Summary: Provide a more secure cmake build Key: MESOS-7737 URL: https://issues.apache.org/jira/browse/MESOS-7737 Project: Mesos Issue Type: Improvement Components: cmake Reporter: Aaron Wood Assignee: Aaron Wood Priority: Minor Apply stack protectors (stronger stack protectors with newer compilers), position independent code suitable for linking into executables, security warnings, and generate position independent executables. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (MESOS-7703) Mesos fails to exec a custom executor when no shell is used
[
https://issues.apache.org/jira/browse/MESOS-7703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aaron Wood updated MESOS-7703:
--
Summary: Mesos fails to exec a custom executor when no shell is used (was:
Mesos fails to exec the custom executor when no shell is used)
> Mesos fails to exec a custom executor when no shell is used
> ---
>
> Key: MESOS-7703
> URL: https://issues.apache.org/jira/browse/MESOS-7703
> Project: Mesos
> Issue Type: Bug
> Components: agent, executor
>Affects Versions: 1.2.0, 1.2.1, 1.3.0
>Reporter: Aaron Wood
>Assignee: Aaron Wood
>
> If a framework specifies use of its own executor and sets shell to false the
> executor is never found.
> {code}
> ...
> I0620 16:27:55.514834 20273 fetcher.cpp:582] Fetched
> 'http://10.0.2.2:8081/executor' to
> '/tmp/slave/slaves/c41232ba-fba1-4d6c-866c-35380d85716f-S0/frameworks/c41232ba-fba1-4d6c-866c-35380d85716f-/executors/our_executor/runs/b1d11b00-85bf-428a-a1f0-be8de519294e/executor'
> Failed to execute command: No such file or directory
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (MESOS-7703) Mesos fails to exec the custom executor when no shell is used
[
https://issues.apache.org/jira/browse/MESOS-7703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aaron Wood updated MESOS-7703:
--
Description:
If a framework specifies use of its own executor and sets shell to false the
executor is never found.
{code}
...
I0620 16:27:55.514834 20273 fetcher.cpp:582] Fetched
'http://10.0.2.2:8081/executor' to
'/tmp/slave/slaves/c41232ba-fba1-4d6c-866c-35380d85716f-S0/frameworks/c41232ba-fba1-4d6c-866c-35380d85716f-/executors/our_executor/runs/b1d11b00-85bf-428a-a1f0-be8de519294e/executor'
Failed to execute command: No such file or directory
{code}
was:
If a framework specifies use of its own executor and sets shell to false the
executor is never found.
{code}
...
I0620 16:27:55.514834 20273 fetcher.cpp:582] Fetched
'http://10.0.2.2:8081/executor' to
'/tmp/slave/slaves/c41232ba-fba1-4d6c-866c-35380d85716f-S0/frameworks/c41232ba-fba1-4d6c-866c-35380d85716f-/executors/our_executor/runs/b1d11b00-85bf-428a-a1f0-be8de519294e/executor'
Failed to execute command: No such file or directory
{code}
Additionally, the name of the binary is never passed as an argument so
executors making use of argv[0] will fail. The shell takes care of this for you
which is why it's not seen when using a shell.
> Mesos fails to exec the custom executor when no shell is used
> -
>
> Key: MESOS-7703
> URL: https://issues.apache.org/jira/browse/MESOS-7703
> Project: Mesos
> Issue Type: Bug
> Components: agent, executor
>Affects Versions: 1.2.0, 1.2.1, 1.3.0
>Reporter: Aaron Wood
>Assignee: Aaron Wood
>
> If a framework specifies use of its own executor and sets shell to false the
> executor is never found.
> {code}
> ...
> I0620 16:27:55.514834 20273 fetcher.cpp:582] Fetched
> 'http://10.0.2.2:8081/executor' to
> '/tmp/slave/slaves/c41232ba-fba1-4d6c-866c-35380d85716f-S0/frameworks/c41232ba-fba1-4d6c-866c-35380d85716f-/executors/our_executor/runs/b1d11b00-85bf-428a-a1f0-be8de519294e/executor'
> Failed to execute command: No such file or directory
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MESOS-7703) Mesos fails to exec the custom executor when no shell is used
[
https://issues.apache.org/jira/browse/MESOS-7703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16058390#comment-16058390
]
Aaron Wood commented on MESOS-7703:
---
https://reviews.apache.org/r/60280/
> Mesos fails to exec the custom executor when no shell is used
> -
>
> Key: MESOS-7703
> URL: https://issues.apache.org/jira/browse/MESOS-7703
> Project: Mesos
> Issue Type: Bug
> Components: agent, executor
>Affects Versions: 1.2.0, 1.2.1, 1.3.0
>Reporter: Aaron Wood
>Assignee: Aaron Wood
>
> If a framework specifies use of its own executor and sets shell to false the
> executor is never found.
> {code}
> ...
> I0620 16:27:55.514834 20273 fetcher.cpp:582] Fetched
> 'http://10.0.2.2:8081/executor' to
> '/tmp/slave/slaves/c41232ba-fba1-4d6c-866c-35380d85716f-S0/frameworks/c41232ba-fba1-4d6c-866c-35380d85716f-/executors/our_executor/runs/b1d11b00-85bf-428a-a1f0-be8de519294e/executor'
> Failed to execute command: No such file or directory
> {code}
> Additionally, the name of the binary is never passed as an argument so
> executors making use of argv[0] will fail. The shell takes care of this for
> you which is why it's not seen when using a shell.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (MESOS-7703) Mesos fails to exec the custom executor when no shell is used
[
https://issues.apache.org/jira/browse/MESOS-7703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aaron Wood updated MESOS-7703:
--
Description:
If a framework specifies use of its own executor and sets shell to false the
executor is never found.
{code}
...
I0620 16:27:55.514834 20273 fetcher.cpp:582] Fetched
'http://10.0.2.2:8081/executor' to
'/tmp/slave/slaves/c41232ba-fba1-4d6c-866c-35380d85716f-S0/frameworks/c41232ba-fba1-4d6c-866c-35380d85716f-/executors/our_executor/runs/b1d11b00-85bf-428a-a1f0-be8de519294e/executor'
Failed to execute command: No such file or directory
{code}
Additionally, the name of the binary is never passed as an argument so
executors making use of argv[0] will fail. The shell takes care of this for you
which is why it's not seen when using a shell.
was:
If a framework specifies use of its own executor and sets shell to false in the
ExecutorInfo the executor is never found.
{code}
...
I0620 16:27:55.514834 20273 fetcher.cpp:582] Fetched
'http://10.0.2.2:8081/executor' to
'/tmp/slave/slaves/c41232ba-fba1-4d6c-866c-35380d85716f-S0/frameworks/c41232ba-fba1-4d6c-866c-35380d85716f-/executors/our_executor/runs/b1d11b00-85bf-428a-a1f0-be8de519294e/executor'
Failed to execute command: No such file or directory
{code}
Additionally, the name of the binary is never passed as an argument so
executors making use of argv[0] will fail. The shell takes care of this for you
which is why it's not seen when using a shell.
> Mesos fails to exec the custom executor when no shell is used
> -
>
> Key: MESOS-7703
> URL: https://issues.apache.org/jira/browse/MESOS-7703
> Project: Mesos
> Issue Type: Bug
> Components: agent, executor
>Affects Versions: 1.2.0, 1.2.1, 1.3.0
>Reporter: Aaron Wood
>Assignee: Aaron Wood
>
> If a framework specifies use of its own executor and sets shell to false the
> executor is never found.
> {code}
> ...
> I0620 16:27:55.514834 20273 fetcher.cpp:582] Fetched
> 'http://10.0.2.2:8081/executor' to
> '/tmp/slave/slaves/c41232ba-fba1-4d6c-866c-35380d85716f-S0/frameworks/c41232ba-fba1-4d6c-866c-35380d85716f-/executors/our_executor/runs/b1d11b00-85bf-428a-a1f0-be8de519294e/executor'
> Failed to execute command: No such file or directory
> {code}
> Additionally, the name of the binary is never passed as an argument so
> executors making use of argv[0] will fail. The shell takes care of this for
> you which is why it's not seen when using a shell.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (MESOS-7703) Mesos fails to exec the custom executor when no shell is used
[
https://issues.apache.org/jira/browse/MESOS-7703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aaron Wood updated MESOS-7703:
--
Summary: Mesos fails to exec the custom executor when no shell is used
(was: Mesos fails to execvp a custom executor when no shell is used)
> Mesos fails to exec the custom executor when no shell is used
> -
>
> Key: MESOS-7703
> URL: https://issues.apache.org/jira/browse/MESOS-7703
> Project: Mesos
> Issue Type: Bug
> Components: agent, executor
>Affects Versions: 1.2.0, 1.2.1, 1.3.0
>Reporter: Aaron Wood
>Assignee: Aaron Wood
>
> If a framework specifies use of its own executor and sets shell to false in
> the ExecutorInfo the executor is never found.
> {code}
> ...
> I0620 16:27:55.514834 20273 fetcher.cpp:582] Fetched
> 'http://10.0.2.2:8081/executor' to
> '/tmp/slave/slaves/c41232ba-fba1-4d6c-866c-35380d85716f-S0/frameworks/c41232ba-fba1-4d6c-866c-35380d85716f-/executors/our_executor/runs/b1d11b00-85bf-428a-a1f0-be8de519294e/executor'
> Failed to execute command: No such file or directory
> {code}
> Additionally, the name of the binary is never passed as an argument so
> executors making use of argv[0] will fail. The shell takes care of this for
> you which is why it's not seen when using a shell.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (MESOS-7703) Mesos fails to execvp a custom executor when no shell is used
Aaron Wood created MESOS-7703:
-
Summary: Mesos fails to execvp a custom executor when no shell is
used
Key: MESOS-7703
URL: https://issues.apache.org/jira/browse/MESOS-7703
Project: Mesos
Issue Type: Bug
Components: agent, executor
Affects Versions: 1.3.0, 1.2.1, 1.2.0
Reporter: Aaron Wood
Assignee: Aaron Wood
If a framework specifies use of its own executor and sets shell to false in the
ExecutorInfo the executor is never found.
{code}
...
I0620 16:27:55.514834 20273 fetcher.cpp:582] Fetched
'http://10.0.2.2:8081/executor' to
'/tmp/slave/slaves/c41232ba-fba1-4d6c-866c-35380d85716f-S0/frameworks/c41232ba-fba1-4d6c-866c-35380d85716f-/executors/our_executor/runs/b1d11b00-85bf-428a-a1f0-be8de519294e/executor'
Failed to execute command: No such file or directory
{code}
Additionally, the name of the binary is never passed as an argument so
executors making use of argv[0] will fail. The shell takes care of this for you
which is why it's not seen when using a shell.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MESOS-7520) Mesos fails to compile with GCC 7.1
[
https://issues.apache.org/jira/browse/MESOS-7520?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16057647#comment-16057647
]
Aaron Wood commented on MESOS-7520:
---
We still need fixes to the Duration class.
> Mesos fails to compile with GCC 7.1
> ---
>
> Key: MESOS-7520
> URL: https://issues.apache.org/jira/browse/MESOS-7520
> Project: Mesos
> Issue Type: Bug
> Components: agent, build, master
>Affects Versions: 1.2.0
>Reporter: Aaron Wood
>Assignee: Aaron Wood
>Priority: Trivial
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80829
> {code}
> error 12-May-2017 15:46:40In file included from
> ../../src/authorizer/authorizer.cpp:29:0:
> error 12-May-2017 15:46:40../../src/master/constants.hpp:45:39: error:
> 'Megabytes(32).Megabytes::' is not a constant expression because
> it refers to an incompletely initialized variable
> error 12-May-2017 15:46:40 constexpr Bytes MIN_MEM = Megabytes(32);
> error 12-May-2017 15:46:40 ^
> error 12-May-2017 15:46:40../../src/master/constants.hpp:49:59: error:
> 'Seconds(15).Seconds::' is not a constant expression because it
> refers to an incompletely initialized variable
> error 12-May-2017 15:46:40 constexpr Duration DEFAULT_HEARTBEAT_INTERVAL
> = Seconds(15);
> error 12-May-2017 15:46:40
>^
> error 12-May-2017 15:46:40../../src/master/constants.hpp:57:59: error:
> 'Seconds(15).Seconds::' is not a constant expression because it
> refers to an incompletely initialized variable
> error 12-May-2017 15:46:40 constexpr Duration DEFAULT_AGENT_PING_TIMEOUT
> = Seconds(15);
> error 12-May-2017 15:46:40
>^
> error 12-May-2017 15:46:40../../src/master/constants.hpp:67:61: error:
> 'Minutes(10).Minutes::' is not a constant expression because it
> refers to an incompletely initialized variable
> error 12-May-2017 15:46:40 constexpr Duration
> MIN_AGENT_REREGISTER_TIMEOUT = Minutes(10);
> error 12-May-2017 15:46:40
> ^
> error 12-May-2017 15:46:40../../src/master/constants.hpp:95:56: error:
> 'Seconds(5).Seconds::' is not a constant expression because it
> refers to an incompletely initialized variable
> error 12-May-2017 15:46:40 constexpr Duration WHITELIST_WATCH_INTERVAL =
> Seconds(5);
> error 12-May-2017 15:46:40
> ^
> error 12-May-2017 15:46:40../../src/master/constants.hpp:100:61: error:
> 'Minutes(15).Minutes::' is not a constant expression because it
> refers to an incompletely initialized variable
> error 12-May-2017 15:46:40 constexpr Duration
> DEFAULT_REGISTRY_GC_INTERVAL = Minutes(15);
> error 12-May-2017 15:46:40
> ^
> error 12-May-2017 15:46:40../../src/master/constants.hpp:102:60: error:
> 'Weeks(2).Weeks::' is not a constant expression because it refers
> to an incompletely initialized variable
> error 12-May-2017 15:46:40 constexpr Duration
> DEFAULT_REGISTRY_MAX_AGENT_AGE = Weeks(2);
> error 12-May-2017 15:46:40
> ^
> error 12-May-2017 15:46:40../../src/master/constants.hpp:122:58: error:
> 'Seconds(10).Seconds::' is not a constant expression because it
> refers to an incompletely initialized variable
> error 12-May-2017 15:46:40 constexpr Duration ZOOKEEPER_SESSION_TIMEOUT =
> Seconds(10);
> error 12-May-2017 15:46:40
> ^
> error 12-May-2017 15:46:40../../src/master/constants.hpp:131:59: error:
> 'Seconds(1).Seconds::' is not a constant expression because it
> refers to an incompletely initialized variable
> error 12-May-2017 15:46:40 constexpr Duration DEFAULT_ALLOCATION_INTERVAL
> = Seconds(1);
> error 12-May-2017 15:46:40
>^
> error 12-May-2017 15:46:40In file included from
> ../../src/authentication/http/basic_authenticator_factory.cpp:27:0:
> error 12-May-2017 15:46:40../../src/master/constants.hpp:45:39: error:
> 'Megabytes(32).Megabytes::' is not a constant expression because
> it refers to an incompletely initialized variable
> error 12-May-2017 15:46:40 constexpr Bytes MIN_MEM = Megabytes(32);
> error 12-May-2017 15:46:40 ^
> error 12-May-2017 15:46:40../../src/master/constants.hpp:49:59: error:
> 'Seconds(15).Seconds::' is not a constant expression because it
> refers to an incompletely initialized variable
> error 12-May-2017 15:46:40 constexpr
[jira] [Updated] (MESOS-7572) Attach latest symlink when executor is registered.
[ https://issues.apache.org/jira/browse/MESOS-7572?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aaron Wood updated MESOS-7572: -- Description: This will assist framework developers in making features that need to access the latest sandbox when hitting various operator API endpoints. (was: This will assist framework developers in making features that need to access the latest sandbox when hitting various operator API endpoints. https://reviews.apache.org/r/59641/) > Attach latest symlink when executor is registered. > -- > > Key: MESOS-7572 > URL: https://issues.apache.org/jira/browse/MESOS-7572 > Project: Mesos > Issue Type: Improvement > Components: agent, HTTP API, master >Reporter: Aaron Wood >Assignee: Aaron Wood > > This will assist framework developers in making features that need to access > the latest sandbox when hitting various operator API endpoints. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (MESOS-7572) Attach latest symlink when executor is registered.
[ https://issues.apache.org/jira/browse/MESOS-7572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16037664#comment-16037664 ] Aaron Wood commented on MESOS-7572: --- https://reviews.apache.org/r/59641/ > Attach latest symlink when executor is registered. > -- > > Key: MESOS-7572 > URL: https://issues.apache.org/jira/browse/MESOS-7572 > Project: Mesos > Issue Type: Improvement > Components: agent, HTTP API, master >Reporter: Aaron Wood >Assignee: Aaron Wood > > This will assist framework developers in making features that need to access > the latest sandbox when hitting various operator API endpoints. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (MESOS-7572) Attach latest symlink when executor is registered.
[
https://issues.apache.org/jira/browse/MESOS-7572?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aaron Wood updated MESOS-7572:
--
Description:
This will assist framework developers in making features that need to access
the latest sandbox when hitting various operator API endpoints.
https://reviews.apache.org/r/59641/
was:
The main benefit of following symlinks in endpoints such as {code}/files{code}
is that frameworks will be able to construct a path to the sandbox much easier.
This will assist framework developers in making features that need to provide a
path when hitting various operator API endpoints. Currently, making use of a
path ending in {code}runs/latest{code} throws a 404.
One such application could be a scheduler providing the ability for users to
work with their task's sandbox directly without going to the Mesos UI, API
endpoints, or the actual system themselves.
https://reviews.apache.org/r/59641/
> Attach latest symlink when executor is registered.
> --
>
> Key: MESOS-7572
> URL: https://issues.apache.org/jira/browse/MESOS-7572
> Project: Mesos
> Issue Type: Improvement
> Components: agent, HTTP API, master
>Reporter: Aaron Wood
>Assignee: Aaron Wood
>
> This will assist framework developers in making features that need to access
> the latest sandbox when hitting various operator API endpoints.
> https://reviews.apache.org/r/59641/
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (MESOS-7572) Attach latest symlink when executor is registered.
[
https://issues.apache.org/jira/browse/MESOS-7572?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aaron Wood updated MESOS-7572:
--
Summary: Attach latest symlink when executor is registered. (was: Follow
symlinks when resolving paths in the various master/agent endpoints)
> Attach latest symlink when executor is registered.
> --
>
> Key: MESOS-7572
> URL: https://issues.apache.org/jira/browse/MESOS-7572
> Project: Mesos
> Issue Type: Improvement
> Components: agent, HTTP API, master
>Reporter: Aaron Wood
>Assignee: Aaron Wood
>
> The main benefit of following symlinks in endpoints such as
> {code}/files{code} is that frameworks will be able to construct a path to the
> sandbox much easier. This will assist framework developers in making features
> that need to provide a path when hitting various operator API endpoints.
> Currently, making use of a path ending in {code}runs/latest{code} throws a
> 404.
> One such application could be a scheduler providing the ability for users to
> work with their task's sandbox directly without going to the Mesos UI, API
> endpoints, or the actual system themselves.
> https://reviews.apache.org/r/59641/
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (MESOS-7622) Agent crashes if the default executor launches a custom executor which then tries to subscribe
Aaron Wood created MESOS-7622:
-
Summary: Agent crashes if the default executor launches a custom
executor which then tries to subscribe
Key: MESOS-7622
URL: https://issues.apache.org/jira/browse/MESOS-7622
Project: Mesos
Issue Type: Bug
Components: agent, executor
Reporter: Aaron Wood
Assignee: Anand Mazumdar
Priority: Blocker
{code}
sudo ./mesos-agent --master=10.0.2.15:5050 --work_dir=/tmp/slave
--isolation=cgroups/cpu,cgroups/mem,disk/du,network/cni,filesystem/linux,docker/runtime
--image_providers=docker --image_provisioner_backend=overlay
--containerizers=mesos --launcher_dir=$(pwd)
--executor_environment_variables='{"LD_LIBRARY_PATH":
"/home/aaron/Code/src/mesos/build/src/.libs"}'
WARNING: Logging before InitGoogleLogging() is written to STDERR
I0605 14:58:23.748180 10710 main.cpp:323] Build: 2017-06-02 17:09:05 UTC by
aaron
I0605 14:58:23.748252 10710 main.cpp:324] Version: 1.4.0
I0605 14:58:23.755409 10710 systemd.cpp:238] systemd version `232` detected
I0605 14:58:23.755450 10710 main.cpp:433] Initializing systemd state
I0605 14:58:23.763049 10710 systemd.cpp:326] Started systemd slice
`mesos_executors.slice`
I0605 14:58:23.763777 10710 resolver.cpp:69] Creating default secret resolver
I0605 14:58:23.764214 10710 containerizer.cpp:230] Using isolation:
cgroups/cpu,cgroups/mem,disk/du,network/cni,filesystem/linux,docker/runtime,volume/image,environment_secret
I0605 14:58:23.767192 10710 linux_launcher.cpp:150] Using
/sys/fs/cgroup/freezer as the freezer hierarchy for the Linux launcher
E0605 14:58:23.770179 10710 shell.hpp:107] Command 'hadoop version 2>&1'
failed; this is the output:
sh: 1: hadoop: not found
I0605 14:58:23.770217 10710 fetcher.cpp:69] Skipping URI fetcher plugin
'hadoop' as it could not be created: Failed to create HDFS client: Failed to
execute 'hadoop version 2>&1'; the command was either not found or exited with
a non-zero exit status: 127
I0605 14:58:23.770643 10710 provisioner.cpp:255] Using default backend 'overlay'
I0605 14:58:23.785892 10710 slave.cpp:248] Mesos agent started on
(1)@127.0.1.1:5051
I0605 14:58:23.785957 10710 slave.cpp:249] Flags at startup:
--appc_simple_discovery_uri_prefix="http://;
--appc_store_dir="/tmp/mesos/store/appc" --authenticate_http_readonly="false"
--authenticate_http_readwrite="false" --authenticatee="crammd5"
--authentication_backoff_factor="1secs" --authorizer="local"
--cgroups_cpu_enable_pids_and_tids_count="false" --cgroups_enable_cfs="false"
--cgroups_hierarchy="/sys/fs/cgroup" --cgroups_limit_swap="false"
--cgroups_root="mesos" --container_disk_watch_interval="15secs"
--containerizers="mesos" --default_role="*" --disk_watch_interval="1mins"
--docker="docker" --docker_kill_orphans="true"
--docker_registry="https://registry-1.docker.io; --docker_remove_delay="6hrs"
--docker_socket="/var/run/docker.sock" --docker_stop_timeout="0ns"
--docker_store_dir="/tmp/mesos/store/docker"
--docker_volume_checkpoint_dir="/var/run/mesos/isolators/docker/volume"
--enforce_container_disk_quota="false"
--executor_environment_variables="{"LD_LIBRARY_PATH":"\/home\/aaron\/Code\/src\/mesos\/build\/src\/.libs"}"
--executor_registration_timeout="1mins"
--executor_reregistration_timeout="2secs"
--executor_shutdown_grace_period="5secs" --fetcher_cache_dir="/tmp/mesos/fetch"
--fetcher_cache_size="2GB" --frameworks_home="" --gc_delay="1weeks"
--gc_disk_headroom="0.1" --hadoop_home="" --help="false"
--hostname_lookup="true" --http_command_executor="false"
--http_heartbeat_interval="30secs" --image_providers="docker"
--image_provisioner_backend="overlay" --initialize_driver_logging="true"
--isolation="cgroups/cpu,cgroups/mem,disk/du,network/cni,filesystem/linux,docker/runtime"
--launcher="linux" --launcher_dir="/home/aaron/Code/src/mesos/build/src"
--logbufsecs="0" --logging_level="INFO" --master="10.0.2.15:5050"
--max_completed_executors_per_framework="150"
--oversubscribed_resources_interval="15secs" --perf_duration="10secs"
--perf_interval="1mins" --port="5051" --qos_correction_interval_min="0ns"
--quiet="false" --recover="reconnect" --recovery_timeout="15mins"
--registration_backoff_factor="1secs" --revocable_cpu_low_priority="true"
--runtime_dir="/var/run/mesos" --sandbox_directory="/mnt/mesos/sandbox"
--strict="true" --switch_user="true" --systemd_enable_support="true"
--systemd_runtime_directory="/run/systemd/system" --version="false"
--work_dir="/tmp/slave"
I0605 14:58:23.786392 10710 slave.cpp:552] Agent resources: cpus(*):6;
mem(*):6956; disk(*):41113; ports(*):[31000-32000]
I0605 14:58:23.786437 10710 slave.cpp:560] Agent attributes: [ ]
I0605 14:58:23.786468 10710 slave.cpp:565] Agent hostname: U64
I0605 14:58:23.786574 10714 status_update_manager.cpp:177] Pausing sending
status updates
I0605 14:58:23.787470 10718 state.cpp:62] Recovering state from
[jira] [Updated] (MESOS-7572) Follow symlinks when resolving paths in the various master/agent endpoints
[
https://issues.apache.org/jira/browse/MESOS-7572?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aaron Wood updated MESOS-7572:
--
Description:
The main benefit of following symlinks in endpoints such as {code}/files{code}
is that frameworks will be able to construct a path to the sandbox much easier.
This will assist framework developers in making features that need to provide a
path when hitting various operator API endpoints. Currently, making use of a
path ending in {code}runs/latest{code} throws a 404.
One such application could be a scheduler providing the ability for users to
work with their task's sandbox directly without going to the Mesos UI, API
endpoints, or the actual system themselves.
https://reviews.apache.org/r/59641/
was:
The main benefit of following symlinks in endpoints such as {code}/files{code}
is that frameworks will be able to construct a path to the sandbox much easier.
This will assist framework developers in making features that need to provide a
path when hitting various operator API endpoints. Currently, making use of a
path ending in {code}runs/latest{code} throws a 404.
One such application could be a scheduler providing the ability for users to
work with their task's sandbox directly without going to the Mesos UI, API
endpoints, or the actual system themselves.
> Follow symlinks when resolving paths in the various master/agent endpoints
> --
>
> Key: MESOS-7572
> URL: https://issues.apache.org/jira/browse/MESOS-7572
> Project: Mesos
> Issue Type: Improvement
> Components: agent, HTTP API, master
>Reporter: Aaron Wood
>Assignee: Aaron Wood
>
> The main benefit of following symlinks in endpoints such as
> {code}/files{code} is that frameworks will be able to construct a path to the
> sandbox much easier. This will assist framework developers in making features
> that need to provide a path when hitting various operator API endpoints.
> Currently, making use of a path ending in {code}runs/latest{code} throws a
> 404.
> One such application could be a scheduler providing the ability for users to
> work with their task's sandbox directly without going to the Mesos UI, API
> endpoints, or the actual system themselves.
> https://reviews.apache.org/r/59641/
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (MESOS-7572) Follow symlinks when resolving paths in the various master/agent endpoints
[
https://issues.apache.org/jira/browse/MESOS-7572?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aaron Wood updated MESOS-7572:
--
Description:
The main benefit of following symlinks in endpoints such as {code}/files{code}
is that frameworks will be able to construct a path to the sandbox much easier.
This will assist framework developers in making features that need to provide a
path when hitting various operator API endpoints. Currently, making use of a
path ending in {code}runs/latest{code} throws a 404.
One such application could be a scheduler providing the ability for users to
work with their task's sandbox directly without going to the Mesos UI, API
endpoints, or the actual system themselves.
was:
The main benefit of following symlinks in endpoints such as {code}/files{code}
is that frameworks will be able to construct a path to the sandbox much easier.
This will assist framework developers in making features that need to provide a
path when hitting various operator API endpoints. Currently, making use of a
path ending in {code}runs/latest{code} throws a 404.
One such application could be a scheduler providing the ability for users to
work with their task's sandbox directly without going to the Mesos UI,
endpoints, or the actual system themselves.
> Follow symlinks when resolving paths in the various master/agent endpoints
> --
>
> Key: MESOS-7572
> URL: https://issues.apache.org/jira/browse/MESOS-7572
> Project: Mesos
> Issue Type: Improvement
> Components: agent, HTTP API, master
>Reporter: Aaron Wood
>Assignee: Aaron Wood
>
> The main benefit of following symlinks in endpoints such as
> {code}/files{code} is that frameworks will be able to construct a path to the
> sandbox much easier. This will assist framework developers in making features
> that need to provide a path when hitting various operator API endpoints.
> Currently, making use of a path ending in {code}runs/latest{code} throws a
> 404.
> One such application could be a scheduler providing the ability for users to
> work with their task's sandbox directly without going to the Mesos UI, API
> endpoints, or the actual system themselves.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (MESOS-7572) Follow symlinks when resolving paths in the various master/agent endpoints
[
https://issues.apache.org/jira/browse/MESOS-7572?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aaron Wood updated MESOS-7572:
--
Summary: Follow symlinks when resolving paths in the various master/agent
endpoints (was: Follow symlinks in the various master/agent endpoints)
> Follow symlinks when resolving paths in the various master/agent endpoints
> --
>
> Key: MESOS-7572
> URL: https://issues.apache.org/jira/browse/MESOS-7572
> Project: Mesos
> Issue Type: Improvement
> Components: agent, HTTP API, master
>Reporter: Aaron Wood
>Assignee: Aaron Wood
>
> The main benefit of following symlinks in endpoints such as
> {code}/files{code} is that frameworks will be able to construct a path to the
> sandbox much easier. This will assist framework developers in making features
> that need to provide a path when hitting various operator API endpoints.
> Currently, making use of a path ending in {code}runs/latest{code} throws a
> 404.
> One such application could be a scheduler providing the ability for users to
> work with their task's sandbox directly without going to the Mesos UI,
> endpoints, or the actual system themselves.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (MESOS-7572) Follow symlinks in the various master/agent endpoints
Aaron Wood created MESOS-7572:
-
Summary: Follow symlinks in the various master/agent endpoints
Key: MESOS-7572
URL: https://issues.apache.org/jira/browse/MESOS-7572
Project: Mesos
Issue Type: Improvement
Components: agent, HTTP API, master
Reporter: Aaron Wood
Assignee: Aaron Wood
The main benefit of following symlinks in endpoints such as {code}/files{code}
is that frameworks will be able to construct a path to the sandbox much easier.
This will assist framework developers in making features that need to provide a
path when hitting various operator API endpoints. Currently, making use of a
path ending in {code}runs/latest{code} throws a 404.
One such application could be a scheduler providing the ability for users to
work with their task's sandbox directly without going to the Mesos UI,
endpoints, or the actual system themselves.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (MESOS-7559) CMake builds using parallel execution fail on OS X
[
https://issues.apache.org/jira/browse/MESOS-7559?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aaron Wood updated MESOS-7559:
--
Description:
When doing a {code}cmake -DCMAKE_BUILD_TYPE=Release -DENABLE_DEBUG=0 .. && make
-j4{code} there are some strange transient errors that pop up:
{code}
Scanning dependencies of target boost-1.53.0
/usr/local/Cellar/cmake/3.8.1/bin/cmake -E make_directory
/Users/myusername/Code/src/mesos/src
/Applications/Xcode.app/Contents/Developer/usr/bin/make -f
CMakeFiles/make_bin_include_dir.dir/build.make
CMakeFiles/make_bin_include_dir.dir/build
make[1]: /Applications/Xcode.app/Contents/Developer/usr/bin/make: Permission
denied
make[1]: *** [3rdparty/CMakeFiles/protobuf-2.6.1.dir/all] Error 1
make[1]: *** Waiting for unfinished jobs
/Applications/Xcode.app/Contents/Developer/usr/bin/make -f
3rdparty/CMakeFiles/boost-1.53.0.dir/build.make
3rdparty/CMakeFiles/boost-1.53.0.dir/build
make[1]: /Applications/Xcode.app/Contents/Developer/usr/bin/make: Permission
denied
make[1]: *** [CMakeFiles/make_bin_include_dir.dir/all] Error 1
make[1]: *** [3rdparty/CMakeFiles/boost-1.53.0.dir/all] Error 1
[ 0%] Built target make_bin_src_dir
make: *** [all] Error 2
{code}
{code}
/usr/include/assert.h:93:25: note: expanded from macro 'assert'
(__builtin_expect(!(e), 0) ? __assert_rtn(__func__, __FILE__, __LINE__, #e)
: (void)0)
^
29 warnings generated.
libtool: compile: gcc -DHAVE_CONFIG_H -I.
-I/Users/myusername/Code/src/mesos/build/3rdparty/libev-4.22/src/libev-4.22 -g
-O3 -MT ev.lo -MD -MP -MF .deps/ev.Tpo -c
/Users/myusername/Code/src/mesos/build/3rdparty/libev-4.22/src/libev-4.22/ev.c
-o ev.o >/dev/null 2>&1
mv -f .deps/ev.Tpo .deps/ev.Plo
/bin/sh ./libtool --tag=CC --mode=link gcc -g -O3 -version-info 4:0:0 -o
libev.la -rpath
/Users/myusername/Code/src/mesos/build/3rdparty/libev-4.22/src/libev-4.22-lib/lib
ev.lo event.lo
libtool: link: gcc -dynamiclib -Wl,-undefined -Wl,dynamic_lookup -o
.libs/libev.4.dylib .libs/ev.o .libs/event.o-O3 -install_name
/Users/myusername/Code/src/mesos/build/3rdparty/libev-4.22/src/libev-4.22-lib/lib/libev.4.dylib
-compatibility_version 5 -current_version 5.0 -Wl,-single_module
libtool: link: (cd ".libs" && rm -f "libev.dylib" && ln -s "libev.4.dylib"
"libev.dylib")
libtool: link: ar cru .libs/libev.a ev.o event.o
libtool: link: ranlib .libs/libev.a
libtool: link: ( cd ".libs" && rm -f "libev.la" && ln -s "../libev.la"
"libev.la" )
cd
/Users/myusername/Code/src/mesos/build/3rdparty/libev-4.22/src/libev-4.22-build
&& /usr/local/Cellar/cmake/3.8.1/bin/cmake -E touch
/Users/myusername/Code/src/mesos/build/3rdparty/libev-4.22/src/libev-4.22-stamp/libev-4.22-build
[ 4%] Performing install step for 'libev-4.22'
cd
/Users/myusername/Code/src/mesos/build/3rdparty/libev-4.22/src/libev-4.22-build
&& mkdir -p
/Users/myusername/Code/src/mesos/build/3rdparty/libev-4.22/src/libev-4.22-lib/lib
&& cp -r
/Users/myusername/Code/src/mesos/build/3rdparty/libev-4.22/src/libev-4.22-build/.libs/.
/Users/myusername/Code/src/mesos/build/3rdparty/libev-4.22/src/libev-4.22-lib/lib
cd
/Users/myusername/Code/src/mesos/build/3rdparty/libev-4.22/src/libev-4.22-build
&& /usr/local/Cellar/cmake/3.8.1/bin/cmake -E touch
/Users/myusername/Code/src/mesos/build/3rdparty/libev-4.22/src/libev-4.22-stamp/libev-4.22-install
[ 6%] Completed 'libev-4.22'
cd /Users/myusername/Code/src/mesos/build/3rdparty &&
/usr/local/Cellar/cmake/3.8.1/bin/cmake -E make_directory
/Users/myusername/Code/src/mesos/build/3rdparty/CMakeFiles
cd /Users/myusername/Code/src/mesos/build/3rdparty &&
/usr/local/Cellar/cmake/3.8.1/bin/cmake -E touch
/Users/myusername/Code/src/mesos/build/3rdparty/CMakeFiles/libev-4.22-complete
cd /Users/myusername/Code/src/mesos/build/3rdparty &&
/usr/local/Cellar/cmake/3.8.1/bin/cmake -E touch
/Users/myusername/Code/src/mesos/build/3rdparty/libev-4.22/src/libev-4.22-stamp/libev-4.22-done
[ 6%] Built target libev-4.22
make: *** [all] Error 2
{code}
And there seems to be an impassable error further along:
{code}
[ 27%] Completed 'glog-0.3.3'
cd /Users/myusername/Code/src/mesos/build/3rdparty &&
/usr/local/Cellar/cmake/3.8.1/bin/cmake -E make_directory
/Users/myusername/Code/src/mesos/build/3rdparty/CMakeFiles
cd /Users/myusername/Code/src/mesos/build/3rdparty &&
/usr/local/Cellar/cmake/3.8.1/bin/cmake -E touch
/Users/myusername/Code/src/mesos/build/3rdparty/CMakeFiles/glog-0.3.3-complete
cd /Users/myusername/Code/src/mesos/build/3rdparty &&
/usr/local/Cellar/cmake/3.8.1/bin/cmake -E touch
/Users/myusername/Code/src/mesos/build/3rdparty/glog-0.3.3/src/glog-0.3.3-stamp/glog-0.3.3-done
gmake[2]: Leaving directory '/Users/myusername/Code/src/mesos/build'
[ 27%] Built target glog-0.3.3
gmake[1]: Leaving directory '/Users/myusername/Code/src/mesos/build'
gmake: *** [Makefile:120: all] Error 2
{code}
was:
There are some strange transient
[jira] [Created] (MESOS-7559) CMake builds using parallel execution fail on OS X
Aaron Wood created MESOS-7559:
-
Summary: CMake builds using parallel execution fail on OS X
Key: MESOS-7559
URL: https://issues.apache.org/jira/browse/MESOS-7559
Project: Mesos
Issue Type: Bug
Components: build, cmake
Reporter: Aaron Wood
Assignee: Andrew Schwartzmeyer
Priority: Minor
There are some strange transient errors that pop up:
{code}
Scanning dependencies of target boost-1.53.0
/usr/local/Cellar/cmake/3.8.1/bin/cmake -E make_directory
/Users/myusername/Code/src/mesos/src
/Applications/Xcode.app/Contents/Developer/usr/bin/make -f
CMakeFiles/make_bin_include_dir.dir/build.make
CMakeFiles/make_bin_include_dir.dir/build
make[1]: /Applications/Xcode.app/Contents/Developer/usr/bin/make: Permission
denied
make[1]: *** [3rdparty/CMakeFiles/protobuf-2.6.1.dir/all] Error 1
make[1]: *** Waiting for unfinished jobs
/Applications/Xcode.app/Contents/Developer/usr/bin/make -f
3rdparty/CMakeFiles/boost-1.53.0.dir/build.make
3rdparty/CMakeFiles/boost-1.53.0.dir/build
make[1]: /Applications/Xcode.app/Contents/Developer/usr/bin/make: Permission
denied
make[1]: *** [CMakeFiles/make_bin_include_dir.dir/all] Error 1
make[1]: *** [3rdparty/CMakeFiles/boost-1.53.0.dir/all] Error 1
[ 0%] Built target make_bin_src_dir
make: *** [all] Error 2
{code}
{code}
/usr/include/assert.h:93:25: note: expanded from macro 'assert'
(__builtin_expect(!(e), 0) ? __assert_rtn(__func__, __FILE__, __LINE__, #e)
: (void)0)
^
29 warnings generated.
libtool: compile: gcc -DHAVE_CONFIG_H -I.
-I/Users/myusername/Code/src/mesos/build/3rdparty/libev-4.22/src/libev-4.22 -g
-O3 -MT ev.lo -MD -MP -MF .deps/ev.Tpo -c
/Users/myusername/Code/src/mesos/build/3rdparty/libev-4.22/src/libev-4.22/ev.c
-o ev.o >/dev/null 2>&1
mv -f .deps/ev.Tpo .deps/ev.Plo
/bin/sh ./libtool --tag=CC --mode=link gcc -g -O3 -version-info 4:0:0 -o
libev.la -rpath
/Users/myusername/Code/src/mesos/build/3rdparty/libev-4.22/src/libev-4.22-lib/lib
ev.lo event.lo
libtool: link: gcc -dynamiclib -Wl,-undefined -Wl,dynamic_lookup -o
.libs/libev.4.dylib .libs/ev.o .libs/event.o-O3 -install_name
/Users/myusername/Code/src/mesos/build/3rdparty/libev-4.22/src/libev-4.22-lib/lib/libev.4.dylib
-compatibility_version 5 -current_version 5.0 -Wl,-single_module
libtool: link: (cd ".libs" && rm -f "libev.dylib" && ln -s "libev.4.dylib"
"libev.dylib")
libtool: link: ar cru .libs/libev.a ev.o event.o
libtool: link: ranlib .libs/libev.a
libtool: link: ( cd ".libs" && rm -f "libev.la" && ln -s "../libev.la"
"libev.la" )
cd
/Users/myusername/Code/src/mesos/build/3rdparty/libev-4.22/src/libev-4.22-build
&& /usr/local/Cellar/cmake/3.8.1/bin/cmake -E touch
/Users/myusername/Code/src/mesos/build/3rdparty/libev-4.22/src/libev-4.22-stamp/libev-4.22-build
[ 4%] Performing install step for 'libev-4.22'
cd
/Users/myusername/Code/src/mesos/build/3rdparty/libev-4.22/src/libev-4.22-build
&& mkdir -p
/Users/myusername/Code/src/mesos/build/3rdparty/libev-4.22/src/libev-4.22-lib/lib
&& cp -r
/Users/myusername/Code/src/mesos/build/3rdparty/libev-4.22/src/libev-4.22-build/.libs/.
/Users/myusername/Code/src/mesos/build/3rdparty/libev-4.22/src/libev-4.22-lib/lib
cd
/Users/myusername/Code/src/mesos/build/3rdparty/libev-4.22/src/libev-4.22-build
&& /usr/local/Cellar/cmake/3.8.1/bin/cmake -E touch
/Users/myusername/Code/src/mesos/build/3rdparty/libev-4.22/src/libev-4.22-stamp/libev-4.22-install
[ 6%] Completed 'libev-4.22'
cd /Users/myusername/Code/src/mesos/build/3rdparty &&
/usr/local/Cellar/cmake/3.8.1/bin/cmake -E make_directory
/Users/myusername/Code/src/mesos/build/3rdparty/CMakeFiles
cd /Users/myusername/Code/src/mesos/build/3rdparty &&
/usr/local/Cellar/cmake/3.8.1/bin/cmake -E touch
/Users/myusername/Code/src/mesos/build/3rdparty/CMakeFiles/libev-4.22-complete
cd /Users/myusername/Code/src/mesos/build/3rdparty &&
/usr/local/Cellar/cmake/3.8.1/bin/cmake -E touch
/Users/myusername/Code/src/mesos/build/3rdparty/libev-4.22/src/libev-4.22-stamp/libev-4.22-done
[ 6%] Built target libev-4.22
make: *** [all] Error 2
{code}
And there seems to be an impassable error further along:
{code}
[ 27%] Completed 'glog-0.3.3'
cd /Users/myusername/Code/src/mesos/build/3rdparty &&
/usr/local/Cellar/cmake/3.8.1/bin/cmake -E make_directory
/Users/myusername/Code/src/mesos/build/3rdparty/CMakeFiles
cd /Users/myusername/Code/src/mesos/build/3rdparty &&
/usr/local/Cellar/cmake/3.8.1/bin/cmake -E touch
/Users/myusername/Code/src/mesos/build/3rdparty/CMakeFiles/glog-0.3.3-complete
cd /Users/myusername/Code/src/mesos/build/3rdparty &&
/usr/local/Cellar/cmake/3.8.1/bin/cmake -E touch
/Users/myusername/Code/src/mesos/build/3rdparty/glog-0.3.3/src/glog-0.3.3-stamp/glog-0.3.3-done
gmake[2]: Leaving directory '/Users/myusername/Code/src/mesos/build'
[ 27%] Built target glog-0.3.3
gmake[1]: Leaving
[jira] [Assigned] (MESOS-7520) Mesos fails to compile with GCC 7.1
[
https://issues.apache.org/jira/browse/MESOS-7520?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aaron Wood reassigned MESOS-7520:
-
Assignee: Aaron Wood
> Mesos fails to compile with GCC 7.1
> ---
>
> Key: MESOS-7520
> URL: https://issues.apache.org/jira/browse/MESOS-7520
> Project: Mesos
> Issue Type: Bug
> Components: agent, build, master
>Affects Versions: 1.2.0
>Reporter: Aaron Wood
>Assignee: Aaron Wood
>Priority: Trivial
>
> {code}
> error 12-May-2017 15:46:40In file included from
> ../../src/authorizer/authorizer.cpp:29:0:
> error 12-May-2017 15:46:40../../src/master/constants.hpp:45:39: error:
> 'Megabytes(32).Megabytes::' is not a constant expression because
> it refers to an incompletely initialized variable
> error 12-May-2017 15:46:40 constexpr Bytes MIN_MEM = Megabytes(32);
> error 12-May-2017 15:46:40 ^
> error 12-May-2017 15:46:40../../src/master/constants.hpp:49:59: error:
> 'Seconds(15).Seconds::' is not a constant expression because it
> refers to an incompletely initialized variable
> error 12-May-2017 15:46:40 constexpr Duration DEFAULT_HEARTBEAT_INTERVAL
> = Seconds(15);
> error 12-May-2017 15:46:40
>^
> error 12-May-2017 15:46:40../../src/master/constants.hpp:57:59: error:
> 'Seconds(15).Seconds::' is not a constant expression because it
> refers to an incompletely initialized variable
> error 12-May-2017 15:46:40 constexpr Duration DEFAULT_AGENT_PING_TIMEOUT
> = Seconds(15);
> error 12-May-2017 15:46:40
>^
> error 12-May-2017 15:46:40../../src/master/constants.hpp:67:61: error:
> 'Minutes(10).Minutes::' is not a constant expression because it
> refers to an incompletely initialized variable
> error 12-May-2017 15:46:40 constexpr Duration
> MIN_AGENT_REREGISTER_TIMEOUT = Minutes(10);
> error 12-May-2017 15:46:40
> ^
> error 12-May-2017 15:46:40../../src/master/constants.hpp:95:56: error:
> 'Seconds(5).Seconds::' is not a constant expression because it
> refers to an incompletely initialized variable
> error 12-May-2017 15:46:40 constexpr Duration WHITELIST_WATCH_INTERVAL =
> Seconds(5);
> error 12-May-2017 15:46:40
> ^
> error 12-May-2017 15:46:40../../src/master/constants.hpp:100:61: error:
> 'Minutes(15).Minutes::' is not a constant expression because it
> refers to an incompletely initialized variable
> error 12-May-2017 15:46:40 constexpr Duration
> DEFAULT_REGISTRY_GC_INTERVAL = Minutes(15);
> error 12-May-2017 15:46:40
> ^
> error 12-May-2017 15:46:40../../src/master/constants.hpp:102:60: error:
> 'Weeks(2).Weeks::' is not a constant expression because it refers
> to an incompletely initialized variable
> error 12-May-2017 15:46:40 constexpr Duration
> DEFAULT_REGISTRY_MAX_AGENT_AGE = Weeks(2);
> error 12-May-2017 15:46:40
> ^
> error 12-May-2017 15:46:40../../src/master/constants.hpp:122:58: error:
> 'Seconds(10).Seconds::' is not a constant expression because it
> refers to an incompletely initialized variable
> error 12-May-2017 15:46:40 constexpr Duration ZOOKEEPER_SESSION_TIMEOUT =
> Seconds(10);
> error 12-May-2017 15:46:40
> ^
> error 12-May-2017 15:46:40../../src/master/constants.hpp:131:59: error:
> 'Seconds(1).Seconds::' is not a constant expression because it
> refers to an incompletely initialized variable
> error 12-May-2017 15:46:40 constexpr Duration DEFAULT_ALLOCATION_INTERVAL
> = Seconds(1);
> error 12-May-2017 15:46:40
>^
> error 12-May-2017 15:46:40In file included from
> ../../src/authentication/http/basic_authenticator_factory.cpp:27:0:
> error 12-May-2017 15:46:40../../src/master/constants.hpp:45:39: error:
> 'Megabytes(32).Megabytes::' is not a constant expression because
> it refers to an incompletely initialized variable
> error 12-May-2017 15:46:40 constexpr Bytes MIN_MEM = Megabytes(32);
> error 12-May-2017 15:46:40 ^
> error 12-May-2017 15:46:40../../src/master/constants.hpp:49:59: error:
> 'Seconds(15).Seconds::' is not a constant expression because it
> refers to an incompletely initialized variable
> error 12-May-2017 15:46:40 constexpr Duration DEFAULT_HEARTBEAT_INTERVAL
> = Seconds(15);
> error 12-May-2017 15:46:40
[jira] [Created] (MESOS-7520) Mesos fails to compile with GCC 7.1
Aaron Wood created MESOS-7520:
-
Summary: Mesos fails to compile with GCC 7.1
Key: MESOS-7520
URL: https://issues.apache.org/jira/browse/MESOS-7520
Project: Mesos
Issue Type: Bug
Components: agent, build, master
Affects Versions: 1.2.0
Reporter: Aaron Wood
Priority: Trivial
{code}
error 12-May-2017 15:46:40In file included from
../../src/authorizer/authorizer.cpp:29:0:
error 12-May-2017 15:46:40../../src/master/constants.hpp:45:39: error:
'Megabytes(32).Megabytes::' is not a constant expression because it
refers to an incompletely initialized variable
error 12-May-2017 15:46:40 constexpr Bytes MIN_MEM = Megabytes(32);
error 12-May-2017 15:46:40 ^
error 12-May-2017 15:46:40../../src/master/constants.hpp:49:59: error:
'Seconds(15).Seconds::' is not a constant expression because it
refers to an incompletely initialized variable
error 12-May-2017 15:46:40 constexpr Duration DEFAULT_HEARTBEAT_INTERVAL
= Seconds(15);
error 12-May-2017 15:46:40
^
error 12-May-2017 15:46:40../../src/master/constants.hpp:57:59: error:
'Seconds(15).Seconds::' is not a constant expression because it
refers to an incompletely initialized variable
error 12-May-2017 15:46:40 constexpr Duration DEFAULT_AGENT_PING_TIMEOUT
= Seconds(15);
error 12-May-2017 15:46:40
^
error 12-May-2017 15:46:40../../src/master/constants.hpp:67:61: error:
'Minutes(10).Minutes::' is not a constant expression because it
refers to an incompletely initialized variable
error 12-May-2017 15:46:40 constexpr Duration
MIN_AGENT_REREGISTER_TIMEOUT = Minutes(10);
error 12-May-2017 15:46:40
^
error 12-May-2017 15:46:40../../src/master/constants.hpp:95:56: error:
'Seconds(5).Seconds::' is not a constant expression because it
refers to an incompletely initialized variable
error 12-May-2017 15:46:40 constexpr Duration WHITELIST_WATCH_INTERVAL =
Seconds(5);
error 12-May-2017 15:46:40
^
error 12-May-2017 15:46:40../../src/master/constants.hpp:100:61: error:
'Minutes(15).Minutes::' is not a constant expression because it
refers to an incompletely initialized variable
error 12-May-2017 15:46:40 constexpr Duration
DEFAULT_REGISTRY_GC_INTERVAL = Minutes(15);
error 12-May-2017 15:46:40
^
error 12-May-2017 15:46:40../../src/master/constants.hpp:102:60: error:
'Weeks(2).Weeks::' is not a constant expression because it refers to
an incompletely initialized variable
error 12-May-2017 15:46:40 constexpr Duration
DEFAULT_REGISTRY_MAX_AGENT_AGE = Weeks(2);
error 12-May-2017 15:46:40
^
error 12-May-2017 15:46:40../../src/master/constants.hpp:122:58: error:
'Seconds(10).Seconds::' is not a constant expression because it
refers to an incompletely initialized variable
error 12-May-2017 15:46:40 constexpr Duration ZOOKEEPER_SESSION_TIMEOUT =
Seconds(10);
error 12-May-2017 15:46:40
^
error 12-May-2017 15:46:40../../src/master/constants.hpp:131:59: error:
'Seconds(1).Seconds::' is not a constant expression because it
refers to an incompletely initialized variable
error 12-May-2017 15:46:40 constexpr Duration DEFAULT_ALLOCATION_INTERVAL
= Seconds(1);
error 12-May-2017 15:46:40
^
error 12-May-2017 15:46:40In file included from
../../src/authentication/http/basic_authenticator_factory.cpp:27:0:
error 12-May-2017 15:46:40../../src/master/constants.hpp:45:39: error:
'Megabytes(32).Megabytes::' is not a constant expression because it
refers to an incompletely initialized variable
error 12-May-2017 15:46:40 constexpr Bytes MIN_MEM = Megabytes(32);
error 12-May-2017 15:46:40 ^
error 12-May-2017 15:46:40../../src/master/constants.hpp:49:59: error:
'Seconds(15).Seconds::' is not a constant expression because it
refers to an incompletely initialized variable
error 12-May-2017 15:46:40 constexpr Duration DEFAULT_HEARTBEAT_INTERVAL
= Seconds(15);
error 12-May-2017 15:46:40
^
error 12-May-2017 15:46:40../../src/master/constants.hpp:57:59: error:
'Seconds(15).Seconds::' is not a constant expression because it
refers to an incompletely initialized variable
error 12-May-2017 15:46:40 constexpr Duration
[jira] [Commented] (MESOS-7499) Allow "insecure registry" in Mesos containerizer through some operator configuration
[
https://issues.apache.org/jira/browse/MESOS-7499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16005384#comment-16005384
]
Aaron Wood commented on MESOS-7499:
---
It'd also be nice to bypass the check for self signed certificates. Here are my
thoughts on enhancing the functionality:
- Allow for non-TLS traffic on any port
- Allow for TLS traffic on any port
- Allow for TLS but bypass the certificate check (a simple -k to curl would do)
for endpoints that are using self signed certificates
> Allow "insecure registry" in Mesos containerizer through some operator
> configuration
>
>
> Key: MESOS-7499
> URL: https://issues.apache.org/jira/browse/MESOS-7499
> Project: Mesos
> Issue Type: Bug
>Reporter: Zhitao Li
>
> Similar to {{--insecure-registry}} for docker daemon, Mesos containerizer
> should allow cluster operator to relax https requirement on certain docker
> registries.
> A practical use case is internal registry addresses hosted on private network
> in a corp: we often trust these addresses and do not want to configure extra
> cert for them.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Comment Edited] (MESOS-7499) Allow "insecure registry" in Mesos containerizer through some operator configuration
[
https://issues.apache.org/jira/browse/MESOS-7499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16005384#comment-16005384
]
Aaron Wood edited comment on MESOS-7499 at 5/10/17 8:52 PM:
It'd also be nice to bypass the check for self signed certificates. Here are my
thoughts on enhancing the existing functionality:
- Allow for non-TLS traffic on any port
- Allow for TLS traffic on any port
- Allow for TLS but bypass the certificate check (a simple -k to curl would do)
for endpoints that are using self signed certificates
was (Author: aaron.wood):
It'd also be nice to bypass the check for self signed certificates. Here are my
thoughts on enhancing the functionality:
- Allow for non-TLS traffic on any port
- Allow for TLS traffic on any port
- Allow for TLS but bypass the certificate check (a simple -k to curl would do)
for endpoints that are using self signed certificates
> Allow "insecure registry" in Mesos containerizer through some operator
> configuration
>
>
> Key: MESOS-7499
> URL: https://issues.apache.org/jira/browse/MESOS-7499
> Project: Mesos
> Issue Type: Bug
>Reporter: Zhitao Li
>
> Similar to {{--insecure-registry}} for docker daemon, Mesos containerizer
> should allow cluster operator to relax https requirement on certain docker
> registries.
> A practical use case is internal registry addresses hosted on private network
> in a corp: we often trust these addresses and do not want to configure extra
> cert for them.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (MESOS-7346) Agent crashes if the task name is too long
[
https://issues.apache.org/jira/browse/MESOS-7346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15963324#comment-15963324
]
Aaron Wood commented on MESOS-7346:
---
I have not verified if this affects <= 0.28.x but I've updated the affected
versions with the ones that look to be vulnerable.
> Agent crashes if the task name is too long
> --
>
> Key: MESOS-7346
> URL: https://issues.apache.org/jira/browse/MESOS-7346
> Project: Mesos
> Issue Type: Bug
> Components: agent
>Affects Versions: 1.0.0, 1.0.1, 1.0.2, 1.1.0, 1.1.1, 1.2.0
>Reporter: Aaron Wood
>Assignee: Aaron Wood
>Priority: Critical
>
> While making a load testing tool that wrongly generated very long task names
> I found that the agent crashes:
> {code}
> I0404 18:59:26.716114 5145 slave.cpp:1701] Launching task 'test
> application43109915684310991568431099156843109915684310991568431099156843109915694310991569431099156943109915694310991569431099156943109915704310991570431099157043109915704310991570431099157143109915704310991571431099157143109915714310991572431099157243109915714310991571-6023D486-022C-40AC-BC24-42D07EFA8CB8'
> for framework 85ed4b54-b2f5-4513-9179-b18de7120f9b-0003
> F0404 18:59:26.716377 5145 paths.cpp:508] CHECK_SOME(mkdir): File name too
> long Failed to create executor directory
> '/tmp/slave/slaves/85ed4b54-b2f5-4513-9179-b18de7120f9b-S0/frameworks/85ed4b54-b2f5-4513-9179-b18de7120f9b-0003/executors/test
>
> application43109915684310991568431099156843109915684310991568431099156843109915694310991569431099156943109915694310991569431099156943109915704310991570431099157043109915704310991570431099157143109915704310991571431099157143109915714310991572431099157243109915714310991571-6023D486-022C-40AC-BC24-42D07EFA8CB8/runs/f913fd46-b0a5-439a-a674-8e4a19aa9df3'
> *** Check failure stack trace: ***
> @ 0x7f247f2f7a46 google::LogMessage::Fail()
> @ 0x7f247f2f798a google::LogMessage::SendToLog()
> @ 0x7f247f2f735c google::LogMessage::Flush()
> @ 0x7f247f2fa61a google::LogMessageFatal::~LogMessageFatal()
> @ 0x480c42 _CheckFatal::~_CheckFatal()
> @ 0x7f247e5046a8
> mesos::internal::slave::paths::createExecutorDirectory()
> @ 0x7f247e540cf9 mesos::internal::slave::Framework::launchExecutor()
> @ 0x7f247e51c337 mesos::internal::slave::Slave::_run()
> @ 0x7f247e577af6
> _ZZN7process8dispatchIN5mesos8internal5slave5SlaveERKNS_6FutureIbEERKNS1_13FrameworkInfoERKNS1_12ExecutorInfoERK6OptionINS1_8TaskInfoEERKSF_INS1_13TaskGroupInfoEES6_S9_SC_SH_SL_EEvRKNS_3PIDIT_EEMSP_FvT0_T1_T2_T3_T4_ET5_T6_T7_T8_T9_ENKUlPNS_11ProcessBaseEE_clES16_
> @ 0x7f247e5af990
> _ZNSt17_Function_handlerIFvPN7process11ProcessBaseEEZNS0_8dispatchIN5mesos8internal5slave5SlaveERKNS0_6FutureIbEERKNS5_13FrameworkInfoERKNS5_12ExecutorInfoERK6OptionINS5_8TaskInfoEERKSJ_INS5_13TaskGroupInfoEESA_SD_SG_SL_SP_EEvRKNS0_3PIDIT_EEMST_FvT0_T1_T2_T3_T4_ET5_T6_T7_T8_T9_EUlS2_E_E9_M_invokeERKSt9_Any_dataOS2_
> @ 0x7f247f284187 std::function<>::operator()()
> @ 0x7f247f26503e process::ProcessBase::visit()
> @ 0x7f247f26dad0 process::DispatchEvent::visit()
> @ 0x7f247dcbea08 process::ProcessBase::serve()
> @ 0x7f247f260efa process::ProcessManager::resume()
> @ 0x7f247f25da22
> _ZZN7process14ProcessManager12init_threadsEvENKUt_clEv
> @ 0x7f247f26d0f2
> _ZNSt12_Bind_simpleIFZN7process14ProcessManager12init_threadsEvEUt_vEE9_M_invokeIJEEEvSt12_Index_tupleIJXspT_EEE
> @ 0x7f247f26d048
> _ZNSt12_Bind_simpleIFZN7process14ProcessManager12init_threadsEvEUt_vEEclEv
> @ 0x7f247f26cfd8
> _ZNSt6thread5_ImplISt12_Bind_simpleIFZN7process14ProcessManager12init_threadsEvEUt_vEEE6_M_runEv
> @ 0x7f2479711c80 (unknown)
> @ 0x7f247922d6ba start_thread
> @ 0x7f2478f6382d (unknown)
> Aborted (core dumped)
> {code}
> https://reviews.apache.org/r/58317/
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (MESOS-7346) Agent crashes if the task name is too long
[
https://issues.apache.org/jira/browse/MESOS-7346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aaron Wood updated MESOS-7346:
--
Affects Version/s: 1.0.0
1.0.1
1.0.2
1.1.0
1.2.0
> Agent crashes if the task name is too long
> --
>
> Key: MESOS-7346
> URL: https://issues.apache.org/jira/browse/MESOS-7346
> Project: Mesos
> Issue Type: Bug
> Components: agent
>Affects Versions: 1.0.0, 1.0.1, 1.0.2, 1.1.0, 1.1.1, 1.2.0
>Reporter: Aaron Wood
>Assignee: Aaron Wood
>Priority: Critical
>
> While making a load testing tool that wrongly generated very long task names
> I found that the agent crashes:
> {code}
> I0404 18:59:26.716114 5145 slave.cpp:1701] Launching task 'test
> application43109915684310991568431099156843109915684310991568431099156843109915694310991569431099156943109915694310991569431099156943109915704310991570431099157043109915704310991570431099157143109915704310991571431099157143109915714310991572431099157243109915714310991571-6023D486-022C-40AC-BC24-42D07EFA8CB8'
> for framework 85ed4b54-b2f5-4513-9179-b18de7120f9b-0003
> F0404 18:59:26.716377 5145 paths.cpp:508] CHECK_SOME(mkdir): File name too
> long Failed to create executor directory
> '/tmp/slave/slaves/85ed4b54-b2f5-4513-9179-b18de7120f9b-S0/frameworks/85ed4b54-b2f5-4513-9179-b18de7120f9b-0003/executors/test
>
> application43109915684310991568431099156843109915684310991568431099156843109915694310991569431099156943109915694310991569431099156943109915704310991570431099157043109915704310991570431099157143109915704310991571431099157143109915714310991572431099157243109915714310991571-6023D486-022C-40AC-BC24-42D07EFA8CB8/runs/f913fd46-b0a5-439a-a674-8e4a19aa9df3'
> *** Check failure stack trace: ***
> @ 0x7f247f2f7a46 google::LogMessage::Fail()
> @ 0x7f247f2f798a google::LogMessage::SendToLog()
> @ 0x7f247f2f735c google::LogMessage::Flush()
> @ 0x7f247f2fa61a google::LogMessageFatal::~LogMessageFatal()
> @ 0x480c42 _CheckFatal::~_CheckFatal()
> @ 0x7f247e5046a8
> mesos::internal::slave::paths::createExecutorDirectory()
> @ 0x7f247e540cf9 mesos::internal::slave::Framework::launchExecutor()
> @ 0x7f247e51c337 mesos::internal::slave::Slave::_run()
> @ 0x7f247e577af6
> _ZZN7process8dispatchIN5mesos8internal5slave5SlaveERKNS_6FutureIbEERKNS1_13FrameworkInfoERKNS1_12ExecutorInfoERK6OptionINS1_8TaskInfoEERKSF_INS1_13TaskGroupInfoEES6_S9_SC_SH_SL_EEvRKNS_3PIDIT_EEMSP_FvT0_T1_T2_T3_T4_ET5_T6_T7_T8_T9_ENKUlPNS_11ProcessBaseEE_clES16_
> @ 0x7f247e5af990
> _ZNSt17_Function_handlerIFvPN7process11ProcessBaseEEZNS0_8dispatchIN5mesos8internal5slave5SlaveERKNS0_6FutureIbEERKNS5_13FrameworkInfoERKNS5_12ExecutorInfoERK6OptionINS5_8TaskInfoEERKSJ_INS5_13TaskGroupInfoEESA_SD_SG_SL_SP_EEvRKNS0_3PIDIT_EEMST_FvT0_T1_T2_T3_T4_ET5_T6_T7_T8_T9_EUlS2_E_E9_M_invokeERKSt9_Any_dataOS2_
> @ 0x7f247f284187 std::function<>::operator()()
> @ 0x7f247f26503e process::ProcessBase::visit()
> @ 0x7f247f26dad0 process::DispatchEvent::visit()
> @ 0x7f247dcbea08 process::ProcessBase::serve()
> @ 0x7f247f260efa process::ProcessManager::resume()
> @ 0x7f247f25da22
> _ZZN7process14ProcessManager12init_threadsEvENKUt_clEv
> @ 0x7f247f26d0f2
> _ZNSt12_Bind_simpleIFZN7process14ProcessManager12init_threadsEvEUt_vEE9_M_invokeIJEEEvSt12_Index_tupleIJXspT_EEE
> @ 0x7f247f26d048
> _ZNSt12_Bind_simpleIFZN7process14ProcessManager12init_threadsEvEUt_vEEclEv
> @ 0x7f247f26cfd8
> _ZNSt6thread5_ImplISt12_Bind_simpleIFZN7process14ProcessManager12init_threadsEvEUt_vEEE6_M_runEv
> @ 0x7f2479711c80 (unknown)
> @ 0x7f247922d6ba start_thread
> @ 0x7f2478f6382d (unknown)
> Aborted (core dumped)
> {code}
> https://reviews.apache.org/r/58317/
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (MESOS-7346) Agent crashes if the task name is too long
[
https://issues.apache.org/jira/browse/MESOS-7346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aaron Wood updated MESOS-7346:
--
Description:
While making a load testing tool that wrongly generated very long task names I
found that the agent crashes:
{code}
I0404 18:59:26.716114 5145 slave.cpp:1701] Launching task 'test
application43109915684310991568431099156843109915684310991568431099156843109915694310991569431099156943109915694310991569431099156943109915704310991570431099157043109915704310991570431099157143109915704310991571431099157143109915714310991572431099157243109915714310991571-6023D486-022C-40AC-BC24-42D07EFA8CB8'
for framework 85ed4b54-b2f5-4513-9179-b18de7120f9b-0003
F0404 18:59:26.716377 5145 paths.cpp:508] CHECK_SOME(mkdir): File name too
long Failed to create executor directory
'/tmp/slave/slaves/85ed4b54-b2f5-4513-9179-b18de7120f9b-S0/frameworks/85ed4b54-b2f5-4513-9179-b18de7120f9b-0003/executors/test
application43109915684310991568431099156843109915684310991568431099156843109915694310991569431099156943109915694310991569431099156943109915704310991570431099157043109915704310991570431099157143109915704310991571431099157143109915714310991572431099157243109915714310991571-6023D486-022C-40AC-BC24-42D07EFA8CB8/runs/f913fd46-b0a5-439a-a674-8e4a19aa9df3'
*** Check failure stack trace: ***
@ 0x7f247f2f7a46 google::LogMessage::Fail()
@ 0x7f247f2f798a google::LogMessage::SendToLog()
@ 0x7f247f2f735c google::LogMessage::Flush()
@ 0x7f247f2fa61a google::LogMessageFatal::~LogMessageFatal()
@ 0x480c42 _CheckFatal::~_CheckFatal()
@ 0x7f247e5046a8
mesos::internal::slave::paths::createExecutorDirectory()
@ 0x7f247e540cf9 mesos::internal::slave::Framework::launchExecutor()
@ 0x7f247e51c337 mesos::internal::slave::Slave::_run()
@ 0x7f247e577af6
_ZZN7process8dispatchIN5mesos8internal5slave5SlaveERKNS_6FutureIbEERKNS1_13FrameworkInfoERKNS1_12ExecutorInfoERK6OptionINS1_8TaskInfoEERKSF_INS1_13TaskGroupInfoEES6_S9_SC_SH_SL_EEvRKNS_3PIDIT_EEMSP_FvT0_T1_T2_T3_T4_ET5_T6_T7_T8_T9_ENKUlPNS_11ProcessBaseEE_clES16_
@ 0x7f247e5af990
_ZNSt17_Function_handlerIFvPN7process11ProcessBaseEEZNS0_8dispatchIN5mesos8internal5slave5SlaveERKNS0_6FutureIbEERKNS5_13FrameworkInfoERKNS5_12ExecutorInfoERK6OptionINS5_8TaskInfoEERKSJ_INS5_13TaskGroupInfoEESA_SD_SG_SL_SP_EEvRKNS0_3PIDIT_EEMST_FvT0_T1_T2_T3_T4_ET5_T6_T7_T8_T9_EUlS2_E_E9_M_invokeERKSt9_Any_dataOS2_
@ 0x7f247f284187 std::function<>::operator()()
@ 0x7f247f26503e process::ProcessBase::visit()
@ 0x7f247f26dad0 process::DispatchEvent::visit()
@ 0x7f247dcbea08 process::ProcessBase::serve()
@ 0x7f247f260efa process::ProcessManager::resume()
@ 0x7f247f25da22 _ZZN7process14ProcessManager12init_threadsEvENKUt_clEv
@ 0x7f247f26d0f2
_ZNSt12_Bind_simpleIFZN7process14ProcessManager12init_threadsEvEUt_vEE9_M_invokeIJEEEvSt12_Index_tupleIJXspT_EEE
@ 0x7f247f26d048
_ZNSt12_Bind_simpleIFZN7process14ProcessManager12init_threadsEvEUt_vEEclEv
@ 0x7f247f26cfd8
_ZNSt6thread5_ImplISt12_Bind_simpleIFZN7process14ProcessManager12init_threadsEvEUt_vEEE6_M_runEv
@ 0x7f2479711c80 (unknown)
@ 0x7f247922d6ba start_thread
@ 0x7f2478f6382d (unknown)
Aborted (core dumped)
{code}
https://reviews.apache.org/r/58317/
was:
While making a load testing tool that wrongly generated very long task names I
found that the agent crashes:
{code}
I0404 18:59:26.716114 5145 slave.cpp:1701] Launching task 'test
application43109915684310991568431099156843109915684310991568431099156843109915694310991569431099156943109915694310991569431099156943109915704310991570431099157043109915704310991570431099157143109915704310991571431099157143109915714310991572431099157243109915714310991571-6023D486-022C-40AC-BC24-42D07EFA8CB8'
for framework 85ed4b54-b2f5-4513-9179-b18de7120f9b-0003
F0404 18:59:26.716377 5145 paths.cpp:508] CHECK_SOME(mkdir): File name too
long Failed to create executor directory
'/tmp/slave/slaves/85ed4b54-b2f5-4513-9179-b18de7120f9b-S0/frameworks/85ed4b54-b2f5-4513-9179-b18de7120f9b-0003/executors/test
application43109915684310991568431099156843109915684310991568431099156843109915694310991569431099156943109915694310991569431099156943109915704310991570431099157043109915704310991570431099157143109915704310991571431099157143109915714310991572431099157243109915714310991571-6023D486-022C-40AC-BC24-42D07EFA8CB8/runs/f913fd46-b0a5-439a-a674-8e4a19aa9df3'
*** Check failure stack trace: ***
@ 0x7f247f2f7a46 google::LogMessage::Fail()
@ 0x7f247f2f798a google::LogMessage::SendToLog()
@ 0x7f247f2f735c google::LogMessage::Flush()
@ 0x7f247f2fa61a google::LogMessageFatal::~LogMessageFatal()
@ 0x480c42 _CheckFatal::~_CheckFatal()
@ 0x7f247e5046a8
[jira] [Assigned] (MESOS-7346) Agent crashes if the task name is too long
[
https://issues.apache.org/jira/browse/MESOS-7346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aaron Wood reassigned MESOS-7346:
-
Assignee: Aaron Wood
> Agent crashes if the task name is too long
> --
>
> Key: MESOS-7346
> URL: https://issues.apache.org/jira/browse/MESOS-7346
> Project: Mesos
> Issue Type: Bug
> Components: agent
>Affects Versions: 1.1.1
>Reporter: Aaron Wood
>Assignee: Aaron Wood
>Priority: Critical
>
> While making a load testing tool that wrongly generated very long task names
> I found that the agent crashes:
> {code}
> I0404 18:59:26.716114 5145 slave.cpp:1701] Launching task 'test
> application43109915684310991568431099156843109915684310991568431099156843109915694310991569431099156943109915694310991569431099156943109915704310991570431099157043109915704310991570431099157143109915704310991571431099157143109915714310991572431099157243109915714310991571-6023D486-022C-40AC-BC24-42D07EFA8CB8'
> for framework 85ed4b54-b2f5-4513-9179-b18de7120f9b-0003
> F0404 18:59:26.716377 5145 paths.cpp:508] CHECK_SOME(mkdir): File name too
> long Failed to create executor directory
> '/tmp/slave/slaves/85ed4b54-b2f5-4513-9179-b18de7120f9b-S0/frameworks/85ed4b54-b2f5-4513-9179-b18de7120f9b-0003/executors/test
>
> application43109915684310991568431099156843109915684310991568431099156843109915694310991569431099156943109915694310991569431099156943109915704310991570431099157043109915704310991570431099157143109915704310991571431099157143109915714310991572431099157243109915714310991571-6023D486-022C-40AC-BC24-42D07EFA8CB8/runs/f913fd46-b0a5-439a-a674-8e4a19aa9df3'
> *** Check failure stack trace: ***
> @ 0x7f247f2f7a46 google::LogMessage::Fail()
> @ 0x7f247f2f798a google::LogMessage::SendToLog()
> @ 0x7f247f2f735c google::LogMessage::Flush()
> @ 0x7f247f2fa61a google::LogMessageFatal::~LogMessageFatal()
> @ 0x480c42 _CheckFatal::~_CheckFatal()
> @ 0x7f247e5046a8
> mesos::internal::slave::paths::createExecutorDirectory()
> @ 0x7f247e540cf9 mesos::internal::slave::Framework::launchExecutor()
> @ 0x7f247e51c337 mesos::internal::slave::Slave::_run()
> @ 0x7f247e577af6
> _ZZN7process8dispatchIN5mesos8internal5slave5SlaveERKNS_6FutureIbEERKNS1_13FrameworkInfoERKNS1_12ExecutorInfoERK6OptionINS1_8TaskInfoEERKSF_INS1_13TaskGroupInfoEES6_S9_SC_SH_SL_EEvRKNS_3PIDIT_EEMSP_FvT0_T1_T2_T3_T4_ET5_T6_T7_T8_T9_ENKUlPNS_11ProcessBaseEE_clES16_
> @ 0x7f247e5af990
> _ZNSt17_Function_handlerIFvPN7process11ProcessBaseEEZNS0_8dispatchIN5mesos8internal5slave5SlaveERKNS0_6FutureIbEERKNS5_13FrameworkInfoERKNS5_12ExecutorInfoERK6OptionINS5_8TaskInfoEERKSJ_INS5_13TaskGroupInfoEESA_SD_SG_SL_SP_EEvRKNS0_3PIDIT_EEMST_FvT0_T1_T2_T3_T4_ET5_T6_T7_T8_T9_EUlS2_E_E9_M_invokeERKSt9_Any_dataOS2_
> @ 0x7f247f284187 std::function<>::operator()()
> @ 0x7f247f26503e process::ProcessBase::visit()
> @ 0x7f247f26dad0 process::DispatchEvent::visit()
> @ 0x7f247dcbea08 process::ProcessBase::serve()
> @ 0x7f247f260efa process::ProcessManager::resume()
> @ 0x7f247f25da22
> _ZZN7process14ProcessManager12init_threadsEvENKUt_clEv
> @ 0x7f247f26d0f2
> _ZNSt12_Bind_simpleIFZN7process14ProcessManager12init_threadsEvEUt_vEE9_M_invokeIJEEEvSt12_Index_tupleIJXspT_EEE
> @ 0x7f247f26d048
> _ZNSt12_Bind_simpleIFZN7process14ProcessManager12init_threadsEvEUt_vEEclEv
> @ 0x7f247f26cfd8
> _ZNSt6thread5_ImplISt12_Bind_simpleIFZN7process14ProcessManager12init_threadsEvEUt_vEEE6_M_runEv
> @ 0x7f2479711c80 (unknown)
> @ 0x7f247922d6ba start_thread
> @ 0x7f2478f6382d (unknown)
> Aborted (core dumped)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (MESOS-7346) Agent crashes if the task name is too long
[
https://issues.apache.org/jira/browse/MESOS-7346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15963054#comment-15963054
]
Aaron Wood commented on MESOS-7346:
---
Good to know, thanks!
> Agent crashes if the task name is too long
> --
>
> Key: MESOS-7346
> URL: https://issues.apache.org/jira/browse/MESOS-7346
> Project: Mesos
> Issue Type: Bug
> Components: agent
>Affects Versions: 1.1.1
>Reporter: Aaron Wood
>Priority: Critical
>
> While making a load testing tool that wrongly generated very long task names
> I found that the agent crashes:
> {code}
> I0404 18:59:26.716114 5145 slave.cpp:1701] Launching task 'test
> application43109915684310991568431099156843109915684310991568431099156843109915694310991569431099156943109915694310991569431099156943109915704310991570431099157043109915704310991570431099157143109915704310991571431099157143109915714310991572431099157243109915714310991571-6023D486-022C-40AC-BC24-42D07EFA8CB8'
> for framework 85ed4b54-b2f5-4513-9179-b18de7120f9b-0003
> F0404 18:59:26.716377 5145 paths.cpp:508] CHECK_SOME(mkdir): File name too
> long Failed to create executor directory
> '/tmp/slave/slaves/85ed4b54-b2f5-4513-9179-b18de7120f9b-S0/frameworks/85ed4b54-b2f5-4513-9179-b18de7120f9b-0003/executors/test
>
> application43109915684310991568431099156843109915684310991568431099156843109915694310991569431099156943109915694310991569431099156943109915704310991570431099157043109915704310991570431099157143109915704310991571431099157143109915714310991572431099157243109915714310991571-6023D486-022C-40AC-BC24-42D07EFA8CB8/runs/f913fd46-b0a5-439a-a674-8e4a19aa9df3'
> *** Check failure stack trace: ***
> @ 0x7f247f2f7a46 google::LogMessage::Fail()
> @ 0x7f247f2f798a google::LogMessage::SendToLog()
> @ 0x7f247f2f735c google::LogMessage::Flush()
> @ 0x7f247f2fa61a google::LogMessageFatal::~LogMessageFatal()
> @ 0x480c42 _CheckFatal::~_CheckFatal()
> @ 0x7f247e5046a8
> mesos::internal::slave::paths::createExecutorDirectory()
> @ 0x7f247e540cf9 mesos::internal::slave::Framework::launchExecutor()
> @ 0x7f247e51c337 mesos::internal::slave::Slave::_run()
> @ 0x7f247e577af6
> _ZZN7process8dispatchIN5mesos8internal5slave5SlaveERKNS_6FutureIbEERKNS1_13FrameworkInfoERKNS1_12ExecutorInfoERK6OptionINS1_8TaskInfoEERKSF_INS1_13TaskGroupInfoEES6_S9_SC_SH_SL_EEvRKNS_3PIDIT_EEMSP_FvT0_T1_T2_T3_T4_ET5_T6_T7_T8_T9_ENKUlPNS_11ProcessBaseEE_clES16_
> @ 0x7f247e5af990
> _ZNSt17_Function_handlerIFvPN7process11ProcessBaseEEZNS0_8dispatchIN5mesos8internal5slave5SlaveERKNS0_6FutureIbEERKNS5_13FrameworkInfoERKNS5_12ExecutorInfoERK6OptionINS5_8TaskInfoEERKSJ_INS5_13TaskGroupInfoEESA_SD_SG_SL_SP_EEvRKNS0_3PIDIT_EEMST_FvT0_T1_T2_T3_T4_ET5_T6_T7_T8_T9_EUlS2_E_E9_M_invokeERKSt9_Any_dataOS2_
> @ 0x7f247f284187 std::function<>::operator()()
> @ 0x7f247f26503e process::ProcessBase::visit()
> @ 0x7f247f26dad0 process::DispatchEvent::visit()
> @ 0x7f247dcbea08 process::ProcessBase::serve()
> @ 0x7f247f260efa process::ProcessManager::resume()
> @ 0x7f247f25da22
> _ZZN7process14ProcessManager12init_threadsEvENKUt_clEv
> @ 0x7f247f26d0f2
> _ZNSt12_Bind_simpleIFZN7process14ProcessManager12init_threadsEvEUt_vEE9_M_invokeIJEEEvSt12_Index_tupleIJXspT_EEE
> @ 0x7f247f26d048
> _ZNSt12_Bind_simpleIFZN7process14ProcessManager12init_threadsEvEUt_vEEclEv
> @ 0x7f247f26cfd8
> _ZNSt6thread5_ImplISt12_Bind_simpleIFZN7process14ProcessManager12init_threadsEvEUt_vEEE6_M_runEv
> @ 0x7f2479711c80 (unknown)
> @ 0x7f247922d6ba start_thread
> @ 0x7f2478f6382d (unknown)
> Aborted (core dumped)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (MESOS-7346) Agent crashes if the task name is too long
[
https://issues.apache.org/jira/browse/MESOS-7346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15956048#comment-15956048
]
Aaron Wood commented on MESOS-7346:
---
No problem, it's always nice to see remote DoS flaws get fixed!
> Agent crashes if the task name is too long
> --
>
> Key: MESOS-7346
> URL: https://issues.apache.org/jira/browse/MESOS-7346
> Project: Mesos
> Issue Type: Bug
> Components: agent
>Affects Versions: 1.1.1
>Reporter: Aaron Wood
>Priority: Critical
>
> While making a load testing tool that wrongly generated very long task names
> I found that the agent crashes:
> {code}
> I0404 18:59:26.716114 5145 slave.cpp:1701] Launching task 'test
> application43109915684310991568431099156843109915684310991568431099156843109915694310991569431099156943109915694310991569431099156943109915704310991570431099157043109915704310991570431099157143109915704310991571431099157143109915714310991572431099157243109915714310991571-6023D486-022C-40AC-BC24-42D07EFA8CB8'
> for framework 85ed4b54-b2f5-4513-9179-b18de7120f9b-0003
> F0404 18:59:26.716377 5145 paths.cpp:508] CHECK_SOME(mkdir): File name too
> long Failed to create executor directory
> '/tmp/slave/slaves/85ed4b54-b2f5-4513-9179-b18de7120f9b-S0/frameworks/85ed4b54-b2f5-4513-9179-b18de7120f9b-0003/executors/test
>
> application43109915684310991568431099156843109915684310991568431099156843109915694310991569431099156943109915694310991569431099156943109915704310991570431099157043109915704310991570431099157143109915704310991571431099157143109915714310991572431099157243109915714310991571-6023D486-022C-40AC-BC24-42D07EFA8CB8/runs/f913fd46-b0a5-439a-a674-8e4a19aa9df3'
> *** Check failure stack trace: ***
> @ 0x7f247f2f7a46 google::LogMessage::Fail()
> @ 0x7f247f2f798a google::LogMessage::SendToLog()
> @ 0x7f247f2f735c google::LogMessage::Flush()
> @ 0x7f247f2fa61a google::LogMessageFatal::~LogMessageFatal()
> @ 0x480c42 _CheckFatal::~_CheckFatal()
> @ 0x7f247e5046a8
> mesos::internal::slave::paths::createExecutorDirectory()
> @ 0x7f247e540cf9 mesos::internal::slave::Framework::launchExecutor()
> @ 0x7f247e51c337 mesos::internal::slave::Slave::_run()
> @ 0x7f247e577af6
> _ZZN7process8dispatchIN5mesos8internal5slave5SlaveERKNS_6FutureIbEERKNS1_13FrameworkInfoERKNS1_12ExecutorInfoERK6OptionINS1_8TaskInfoEERKSF_INS1_13TaskGroupInfoEES6_S9_SC_SH_SL_EEvRKNS_3PIDIT_EEMSP_FvT0_T1_T2_T3_T4_ET5_T6_T7_T8_T9_ENKUlPNS_11ProcessBaseEE_clES16_
> @ 0x7f247e5af990
> _ZNSt17_Function_handlerIFvPN7process11ProcessBaseEEZNS0_8dispatchIN5mesos8internal5slave5SlaveERKNS0_6FutureIbEERKNS5_13FrameworkInfoERKNS5_12ExecutorInfoERK6OptionINS5_8TaskInfoEERKSJ_INS5_13TaskGroupInfoEESA_SD_SG_SL_SP_EEvRKNS0_3PIDIT_EEMST_FvT0_T1_T2_T3_T4_ET5_T6_T7_T8_T9_EUlS2_E_E9_M_invokeERKSt9_Any_dataOS2_
> @ 0x7f247f284187 std::function<>::operator()()
> @ 0x7f247f26503e process::ProcessBase::visit()
> @ 0x7f247f26dad0 process::DispatchEvent::visit()
> @ 0x7f247dcbea08 process::ProcessBase::serve()
> @ 0x7f247f260efa process::ProcessManager::resume()
> @ 0x7f247f25da22
> _ZZN7process14ProcessManager12init_threadsEvENKUt_clEv
> @ 0x7f247f26d0f2
> _ZNSt12_Bind_simpleIFZN7process14ProcessManager12init_threadsEvEUt_vEE9_M_invokeIJEEEvSt12_Index_tupleIJXspT_EEE
> @ 0x7f247f26d048
> _ZNSt12_Bind_simpleIFZN7process14ProcessManager12init_threadsEvEUt_vEEclEv
> @ 0x7f247f26cfd8
> _ZNSt6thread5_ImplISt12_Bind_simpleIFZN7process14ProcessManager12init_threadsEvEUt_vEEE6_M_runEv
> @ 0x7f2479711c80 (unknown)
> @ 0x7f247922d6ba start_thread
> @ 0x7f2478f6382d (unknown)
> Aborted (core dumped)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (MESOS-7346) Agent crashes if the task name is too long
Aaron Wood created MESOS-7346:
-
Summary: Agent crashes if the task name is too long
Key: MESOS-7346
URL: https://issues.apache.org/jira/browse/MESOS-7346
Project: Mesos
Issue Type: Bug
Components: agent
Affects Versions: 1.1.1
Reporter: Aaron Wood
While making a load testing tool that wrongly generated very long task names I
found that the agent crashes:
{code}
I0404 18:59:26.716114 5145 slave.cpp:1701] Launching task 'test
application43109915684310991568431099156843109915684310991568431099156843109915694310991569431099156943109915694310991569431099156943109915704310991570431099157043109915704310991570431099157143109915704310991571431099157143109915714310991572431099157243109915714310991571-6023D486-022C-40AC-BC24-42D07EFA8CB8'
for framework 85ed4b54-b2f5-4513-9179-b18de7120f9b-0003
F0404 18:59:26.716377 5145 paths.cpp:508] CHECK_SOME(mkdir): File name too
long Failed to create executor directory
'/tmp/slave/slaves/85ed4b54-b2f5-4513-9179-b18de7120f9b-S0/frameworks/85ed4b54-b2f5-4513-9179-b18de7120f9b-0003/executors/test
application43109915684310991568431099156843109915684310991568431099156843109915694310991569431099156943109915694310991569431099156943109915704310991570431099157043109915704310991570431099157143109915704310991571431099157143109915714310991572431099157243109915714310991571-6023D486-022C-40AC-BC24-42D07EFA8CB8/runs/f913fd46-b0a5-439a-a674-8e4a19aa9df3'
*** Check failure stack trace: ***
@ 0x7f247f2f7a46 google::LogMessage::Fail()
@ 0x7f247f2f798a google::LogMessage::SendToLog()
@ 0x7f247f2f735c google::LogMessage::Flush()
@ 0x7f247f2fa61a google::LogMessageFatal::~LogMessageFatal()
@ 0x480c42 _CheckFatal::~_CheckFatal()
@ 0x7f247e5046a8
mesos::internal::slave::paths::createExecutorDirectory()
@ 0x7f247e540cf9 mesos::internal::slave::Framework::launchExecutor()
@ 0x7f247e51c337 mesos::internal::slave::Slave::_run()
@ 0x7f247e577af6
_ZZN7process8dispatchIN5mesos8internal5slave5SlaveERKNS_6FutureIbEERKNS1_13FrameworkInfoERKNS1_12ExecutorInfoERK6OptionINS1_8TaskInfoEERKSF_INS1_13TaskGroupInfoEES6_S9_SC_SH_SL_EEvRKNS_3PIDIT_EEMSP_FvT0_T1_T2_T3_T4_ET5_T6_T7_T8_T9_ENKUlPNS_11ProcessBaseEE_clES16_
@ 0x7f247e5af990
_ZNSt17_Function_handlerIFvPN7process11ProcessBaseEEZNS0_8dispatchIN5mesos8internal5slave5SlaveERKNS0_6FutureIbEERKNS5_13FrameworkInfoERKNS5_12ExecutorInfoERK6OptionINS5_8TaskInfoEERKSJ_INS5_13TaskGroupInfoEESA_SD_SG_SL_SP_EEvRKNS0_3PIDIT_EEMST_FvT0_T1_T2_T3_T4_ET5_T6_T7_T8_T9_EUlS2_E_E9_M_invokeERKSt9_Any_dataOS2_
@ 0x7f247f284187 std::function<>::operator()()
@ 0x7f247f26503e process::ProcessBase::visit()
@ 0x7f247f26dad0 process::DispatchEvent::visit()
@ 0x7f247dcbea08 process::ProcessBase::serve()
@ 0x7f247f260efa process::ProcessManager::resume()
@ 0x7f247f25da22 _ZZN7process14ProcessManager12init_threadsEvENKUt_clEv
@ 0x7f247f26d0f2
_ZNSt12_Bind_simpleIFZN7process14ProcessManager12init_threadsEvEUt_vEE9_M_invokeIJEEEvSt12_Index_tupleIJXspT_EEE
@ 0x7f247f26d048
_ZNSt12_Bind_simpleIFZN7process14ProcessManager12init_threadsEvEUt_vEEclEv
@ 0x7f247f26cfd8
_ZNSt6thread5_ImplISt12_Bind_simpleIFZN7process14ProcessManager12init_threadsEvEUt_vEEE6_M_runEv
@ 0x7f2479711c80 (unknown)
@ 0x7f247922d6ba start_thread
@ 0x7f2478f6382d (unknown)
Aborted (core dumped)
{code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (MESOS-6127) Implement suppport for HTTP/2
[ https://issues.apache.org/jira/browse/MESOS-6127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15940982#comment-15940982 ] Aaron Wood commented on MESOS-6127: --- Current design doc is here https://docs.google.com/document/d/1vD8x2l5X6LzrHMCIOcWnx8ky_nT_Y2UIrQUXQB7DdLw/edit I don't have the bandwidth at work to take this on right now but I believe [~ipronin] was interested in taking this further. > Implement suppport for HTTP/2 > - > > Key: MESOS-6127 > URL: https://issues.apache.org/jira/browse/MESOS-6127 > Project: Mesos > Issue Type: Epic > Components: HTTP API, libprocess >Reporter: Aaron Wood > Labels: performance > > HTTP/2 will allow us to take advantage of connection multiplexing, header > compression, streams, server push, etc. Add support for communication over > HTTP/2 between masters and agents, framework endpoints, etc. > Should we support HTTP/2 without TLS? The spec allows for this but most major > browser vendors, libraries, and implementations aren't supporting it unless > TLS is used. If we do require TLS, what can be done to reduce the performance > hit of the TLS handshake? Might need to change more code to make sure that we > are taking advantage of connection sharing so that we can (ideally) only ever > have a one-time TLS handshake per shared connection. > Some ideas for libs: > https://nghttp2.org/documentation/package_README.html - Has encoders/decoders > supporting HPACK https://nghttp2.org/documentation/tutorial-hpack.html > https://nghttp2.org/documentation/libnghttp2_asio.html - Currently marked as > experimental by the nghttp2 docs -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (MESOS-6926) Log incoming bad requests to Mesos
[ https://issues.apache.org/jira/browse/MESOS-6926?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15828581#comment-15828581 ] Aaron Wood commented on MESOS-6926: --- My time has been allocated to other things at work so I will have to see if I can fit it in. > Log incoming bad requests to Mesos > -- > > Key: MESOS-6926 > URL: https://issues.apache.org/jira/browse/MESOS-6926 > Project: Mesos > Issue Type: Wish > Components: HTTP API >Reporter: Aaron Wood >Priority: Minor > > It would be very helpful to log bad requests, maybe with the v1 or v2 logging > levels. This would help in the case of MESOS-6917 assuming that there was no > crash in the first place. > For example, if someone is sending invalid UUID's (which I was) up to Mesos > and gets a bad request they should be able to see logs showing the bad > request and potentially the reason behind it. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-6926) Log incoming bad requests to Mesos
[ https://issues.apache.org/jira/browse/MESOS-6926?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aaron Wood updated MESOS-6926: -- Summary: Log incoming bad requests to Mesos (was: Log bad requests that come from frameworks ) > Log incoming bad requests to Mesos > -- > > Key: MESOS-6926 > URL: https://issues.apache.org/jira/browse/MESOS-6926 > Project: Mesos > Issue Type: Wish > Components: HTTP API >Reporter: Aaron Wood >Priority: Minor > > It would be very helpful to log bad requests, maybe with the v1 or v2 logging > levels. This would help in the case of MESOS-6917 assuming that there was no > crash in the first place. > For example, if someone is sending invalid UUID's (which I was) up to Mesos > and gets a bad request they should be able to see logs showing the bad > request and potentially the reason behind it. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MESOS-6926) Log bad requests that come from frameworks
Aaron Wood created MESOS-6926: - Summary: Log bad requests that come from frameworks Key: MESOS-6926 URL: https://issues.apache.org/jira/browse/MESOS-6926 Project: Mesos Issue Type: Wish Components: HTTP API Reporter: Aaron Wood Priority: Minor It would be very helpful to log bad requests, maybe with the v1 or v2 logging levels. This would help in the case of MESOS-6917 assuming that there was no crash in the first place. For example, if someone is sending invalid UUID's (which I was) up to Mesos and gets a bad request they should be able to see logs showing the bad request and potentially the reason behind it. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-6054) Agent Crash with Malformed UUID when doing TaskUpdate
[
https://issues.apache.org/jira/browse/MESOS-6054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15822240#comment-15822240
]
Aaron Wood commented on MESOS-6054:
---
[~dvonthenen] seems that Mesos expects valid v4 UUIDs. I've submitted a patch
to fix the segfault that occurs https://reviews.apache.org/r/55480/
> Agent Crash with Malformed UUID when doing TaskUpdate
> -
>
> Key: MESOS-6054
> URL: https://issues.apache.org/jira/browse/MESOS-6054
> Project: Mesos
> Issue Type: Bug
> Components: framework api
>Affects Versions: 1.0.0
> Environment: Ubuntu 14.04, Mesos 1.0.0-2.0.89.ubuntu1404, Marathon
> 1.1.2
>Reporter: David vonThenen
>Priority: Minor
> Attachments: _usr_sbin_mesos-slave.0.crash
>
>
> When using the HTTP API using protobufs, if the UUID in a TaskUpdate is
> malformed (in this case, was using a UUID that was base64 encoded), it would
> cause the Agent where the executor is running on to crash and restart.
> Here is a JSON dump of the protobuf used:
> {code}
> {
> "executor_id": {
> "value": "executor-scaleio1"
> },
> "framework_id": {
> "value": "ac8545a7-f8fc-431e-bc36-0239c4460658-0002"
> },
> "type": 2,
> "update": {
> "status": {
> "task_id": {
> "value": "scaleio1"
> },
> "state": 1,
> "source": 2,
> "executor_id": {
> "value": "executor-scaleio1"
> },
> "uuid":
> "WVdVd01EQTFNakF0TkdVeU9TMDBNell3TFdJMk4yUXRPR05sT1RFNU56VmlPREUw"
> }
> }
> }
> {code}
> In the master it looks like is processes the accept calls… but after it
> processes all of them, it looks like the agents are immediately being
> disconnected:
> {code}
> ...
> ...
> I0816 17:53:09.974340 4010 master.cpp:3342] Processing ACCEPT call for
> offers: [ 2bf179c3-004a-49e3-98ab-5a75fa773522-O80 ] on agent
> 2bf179c3-004a-49e3-98ab-5a75fa773522-S7 at slave(1)@172.31.22.211:5051
> (ec2-52-89-227-184.us-west-2.compute.amazonaws.com) for framework
> 2bf179c3-004a-49e3-98ab-5a75fa773522-0001 (ScaleIO Framework)
> W0816 17:53:09.974578 4010 validation.cpp:647] Executor executor-scaleio4
> for task scaleio4 uses less CPUs (None) than the minimum required (0.01).
> Please update your executor, as this will be mandatory in future releases.
> W0816 17:53:09.974604 4010 validation.cpp:659] Executor executor-scaleio4
> for task scaleio4 uses less memory (None) than the minimum required (32MB).
> Please update your executor, as this will be mandatory in future releases.
> I0816 17:53:09.974645 4010 master.cpp:7439] Adding task scaleio4 with
> resources cpus(*):1; mem(*):2048 on agent
> 2bf179c3-004a-49e3-98ab-5a75fa773522-S7
> (ec2-52-89-227-184.us-west-2.compute.amazonaws.com)
> I0816 17:53:09.974668 4010 master.cpp:3831] Launching task scaleio4 of
> framework 2bf179c3-004a-49e3-98ab-5a75fa773522-0001 (ScaleIO Framework) with
> resources cpus(*):1; mem(*):2048 on agent
> 2bf179c3-004a-49e3-98ab-5a75fa773522-S7 at slave(1)@172.31.22.211:5051
> (ec2-52-89-227-184.us-west-2.compute.amazonaws.com)
> I0816 17:53:11.306182 4010 master.cpp:1245] Agent
> 2bf179c3-004a-49e3-98ab-5a75fa773522-S7 at slave(1)@172.31.22.211:5051
> (ec2-52-89-227-184.us-west-2.compute.amazonaws.com) disconnected
> I0816 17:53:11.306335 4010 master.cpp:2784] Disconnecting agent
> 2bf179c3-004a-49e3-98ab-5a75fa773522-S7 at slave(1)@172.31.22.211:5051
> (ec2-52-89-227-184.us-west-2.compute.amazonaws.com)
> I0816 17:53:11.306520 4010 master.cpp:2803] Deactivating agent
> 2bf179c3-004a-49e3-98ab-5a75fa773522-S7 at slave(1)@172.31.22.211:5051
> (ec2-52-89-227-184.us-west-2.compute.amazonaws.com)
> I0816 17:53:11.306676 4010 master.cpp:1264] Removing framework
> 2bf179c3-004a-49e3-98ab-5a75fa773522-0001 (ScaleIO Framework) from
> disconnected agent 2bf179c3-004a-49e3-98ab-5a75fa773522-S7 at
> slave(1)@172.31.22.211:5051
> (ec2-52-89-227-184.us-west-2.compute.amazonaws.com) because the framework is
> not checkpointing
> I0816 17:53:11.306798 4010 master.cpp:6448] Removing framework
> 2bf179c3-004a-49e3-98ab-5a75fa773522-0001 (ScaleIO Framework) from agent
> 2bf179c3-004a-49e3-98ab-5a75fa773522-S7 at slave(1)@172.31.22.211:5051
> (ec2-52-89-227-184.us-west-2.compute.amazonaws.com)
> I0816 17:53:11.306882 4010 master.cpp:6833] Updating the state of task
> scaleio4 of framework 2bf179c3-004a-49e3-98ab-5a75fa773522-0001 (latest
> state: TASK_LOST, status update state: TASK_LOST)
> I0816 17:53:11.306778 4013 hierarchical.cpp:571] Agent
> 2bf179c3-004a-49e3-98ab-5a75fa773522-S7 deactivated
> I0816 17:53:11.307140 4010 master.cpp:6899] Removing task scaleio4 with
> resources cpus(*):1; mem(*):2048 of framework
> 2bf179c3-004a-49e3-98ab-5a75fa773522-0001 on agent
> 2bf179c3-004a-49e3-98ab-5a75fa773522-S7 at
[jira] [Updated] (MESOS-6917) Segfault when the executor sets an invalid UUID when sending a status update.
[
https://issues.apache.org/jira/browse/MESOS-6917?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aaron Wood updated MESOS-6917:
--
Description:
A segfault occurs when an executor sets a UUID that's not a valid v4 UUID and
sends it off to the agent:
{code}
ABORT: (../../3rdparty/stout/include/stout/try.hpp:77): Try::get() but state ==
ERROR: Not a valid UUID
*** Aborted at 1484262968 (unix time) try "date -d @1484262968" if you are
using GNU date ***
PC: @ 0x7efeb6101428 (unknown)
*** SIGABRT (@0x36b7) received by PID 14007 (TID 0x7efeabd29700) from PID
14007; stack trace: ***
@ 0x7efeb64a6390 (unknown)
@ 0x7efeb6101428 (unknown)
@ 0x7efeb610302a (unknown)
@ 0x560df739fa6e _Abort()
@ 0x560df739fa9c _Abort()
@ 0x7efebb53a5ad Try<>::get()
@ 0x7efebb5363d6 Try<>::get()
@ 0x7efebbd84809
mesos::internal::slave::validation::executor::call::validate()
@ 0x7efebbb59b36 mesos::internal::slave::Slave::Http::executor()
@ 0x7efebbc773b8
_ZZN5mesos8internal5slave5Slave10initializeEvENKUlRKN7process4http7RequestEE1_clES7_
@ 0x7efebbcb5808
_ZNSt17_Function_handlerIFN7process6FutureINS0_4http8ResponseEEERKNS2_7RequestEEZN5mesos8internal5slave5Slave10initializeEvEUlS7_E1_E9_M_invokeERKSt9_Any_dataS7_
@ 0x7efebbfb2aea std::function<>::operator()()
@ 0x7efebcb158b8
_ZZZN7process11ProcessBase6_visitERKNS0_12HttpEndpointERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEERKNS_5OwnedINS_4http7RequestNKUlRK6OptionINSD_14authentication20AuthenticationResultEEE0_clESN_ENKUlbE1_clEb
@ 0x7efebcb1a10a
_ZZZNK7process9_DeferredIZZNS_11ProcessBase6_visitERKNS1_12HttpEndpointERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEERKNS_5OwnedINS_4http7RequestNKUlRK6OptionINSE_14authentication20AuthenticationResultEEE0_clESO_EUlbE1_EcvSt8functionIFT_T0_EEINS_6FutureINSE_8ResponseEEERKbEEvENKUlS12_E_clES12_ENKUlvE_clEv
@ 0x7efebcb1c5f8
_ZNSt17_Function_handlerIFN7process6FutureINS0_4http8ResponseEEEvEZZNKS0_9_DeferredIZZNS0_11ProcessBase6_visitERKNS7_12HttpEndpointERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEERKNS0_5OwnedINS2_7RequestNKUlRK6OptionINS2_14authentication20AuthenticationResultEEE0_clEST_EUlbE1_EcvSt8functionIFT_T0_EEIS4_RKbEEvENKUlS14_E_clES14_EUlvE_E9_M_invokeERKSt9_Any_data
@ 0x7efebb5ce8ca std::function<>::operator()()
@ 0x7efebb5c4b27
_ZZN7process8internal8DispatchINS_6FutureINS_4http8ResponseclIRSt8functionIFS5_vS5_RKNS_4UPIDEOT_ENKUlPNS_11ProcessBaseEE_clESI_
@ 0x7efebb5d4e1e
_ZNSt17_Function_handlerIFvPN7process11ProcessBaseEEZNS0_8internal8DispatchINS0_6FutureINS0_4http8ResponseclIRSt8functionIFS9_vS9_RKNS0_4UPIDEOT_EUlS2_E_E9_M_invokeERKSt9_Any_dataOS2_
@ 0x7efebcb30baf std::function<>::operator()()
@ 0x7efebcb13fd6 process::ProcessBase::visit()
@ 0x7efebcb1f3c8 process::DispatchEvent::visit()
@ 0x7efebb3ab2ea process::ProcessBase::serve()
@ 0x7efebcb0fe8a process::ProcessManager::resume()
@ 0x7efebcb0c5a3 _ZZN7process14ProcessManager12init_threadsEvENKUt_clEv
@ 0x7efebcb1ea34
_ZNSt12_Bind_simpleIFZN7process14ProcessManager12init_threadsEvEUt_vEE9_M_invokeIJEEEvSt12_Index_tupleIJXspT_EEE
@ 0x7efebcb1e98a
_ZNSt12_Bind_simpleIFZN7process14ProcessManager12init_threadsEvEUt_vEEclEv
@ 0x7efebcb1e91a
_ZNSt6thread5_ImplISt12_Bind_simpleIFZN7process14ProcessManager12init_threadsEvEUt_vEEE6_M_runEv
@ 0x7efeb6980c80 (unknown)
@ 0x7efeb649c6ba start_thread
@ 0x7efeb61d282d (unknown)
Aborted (core dumped)
{code}
https://reviews.apache.org/r/55480/
was:
A segfault occurs when an executor sends an update with a UUID that's not a
valid v4 UUID and sends it off to the agent:
{code}
ABORT: (../../3rdparty/stout/include/stout/try.hpp:77): Try::get() but state ==
ERROR: Not a valid UUID
*** Aborted at 1484262968 (unix time) try "date -d @1484262968" if you are
using GNU date ***
PC: @ 0x7efeb6101428 (unknown)
*** SIGABRT (@0x36b7) received by PID 14007 (TID 0x7efeabd29700) from PID
14007; stack trace: ***
@ 0x7efeb64a6390 (unknown)
@ 0x7efeb6101428 (unknown)
@ 0x7efeb610302a (unknown)
@ 0x560df739fa6e _Abort()
@ 0x560df739fa9c _Abort()
@ 0x7efebb53a5ad Try<>::get()
@ 0x7efebb5363d6 Try<>::get()
@ 0x7efebbd84809
mesos::internal::slave::validation::executor::call::validate()
@ 0x7efebbb59b36 mesos::internal::slave::Slave::Http::executor()
@ 0x7efebbc773b8
_ZZN5mesos8internal5slave5Slave10initializeEvENKUlRKN7process4http7RequestEE1_clES7_
@ 0x7efebbcb5808
_ZNSt17_Function_handlerIFN7process6FutureINS0_4http8ResponseEEERKNS2_7RequestEEZN5mesos8internal5slave5Slave10initializeEvEUlS7_E1_E9_M_invokeERKSt9_Any_dataS7_
@ 0x7efebbfb2aea std::function<>::operator()()
@
[jira] [Created] (MESOS-6917) Segfault when the executor sets a UUID that is not a valid v4 UUID
Aaron Wood created MESOS-6917:
-
Summary: Segfault when the executor sets a UUID that is not a
valid v4 UUID
Key: MESOS-6917
URL: https://issues.apache.org/jira/browse/MESOS-6917
Project: Mesos
Issue Type: Bug
Affects Versions: 1.1.0, 1.0.2, 1.0.1, 1.0.0
Reporter: Aaron Wood
Assignee: Aaron Wood
Priority: Blocker
A segfault occurs when an executor sets a UUID that's not a valid v4 UUID and
sends it off to the agent:
{code}
ABORT: (../../3rdparty/stout/include/stout/try.hpp:77): Try::get() but state ==
ERROR: Not a valid UUID
*** Aborted at 1484262968 (unix time) try "date -d @1484262968" if you are
using GNU date ***
PC: @ 0x7efeb6101428 (unknown)
*** SIGABRT (@0x36b7) received by PID 14007 (TID 0x7efeabd29700) from PID
14007; stack trace: ***
@ 0x7efeb64a6390 (unknown)
@ 0x7efeb6101428 (unknown)
@ 0x7efeb610302a (unknown)
@ 0x560df739fa6e _Abort()
@ 0x560df739fa9c _Abort()
@ 0x7efebb53a5ad Try<>::get()
@ 0x7efebb5363d6 Try<>::get()
@ 0x7efebbd84809
mesos::internal::slave::validation::executor::call::validate()
@ 0x7efebbb59b36 mesos::internal::slave::Slave::Http::executor()
@ 0x7efebbc773b8
_ZZN5mesos8internal5slave5Slave10initializeEvENKUlRKN7process4http7RequestEE1_clES7_
@ 0x7efebbcb5808
_ZNSt17_Function_handlerIFN7process6FutureINS0_4http8ResponseEEERKNS2_7RequestEEZN5mesos8internal5slave5Slave10initializeEvEUlS7_E1_E9_M_invokeERKSt9_Any_dataS7_
@ 0x7efebbfb2aea std::function<>::operator()()
@ 0x7efebcb158b8
_ZZZN7process11ProcessBase6_visitERKNS0_12HttpEndpointERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEERKNS_5OwnedINS_4http7RequestNKUlRK6OptionINSD_14authentication20AuthenticationResultEEE0_clESN_ENKUlbE1_clEb
@ 0x7efebcb1a10a
_ZZZNK7process9_DeferredIZZNS_11ProcessBase6_visitERKNS1_12HttpEndpointERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEERKNS_5OwnedINS_4http7RequestNKUlRK6OptionINSE_14authentication20AuthenticationResultEEE0_clESO_EUlbE1_EcvSt8functionIFT_T0_EEINS_6FutureINSE_8ResponseEEERKbEEvENKUlS12_E_clES12_ENKUlvE_clEv
@ 0x7efebcb1c5f8
_ZNSt17_Function_handlerIFN7process6FutureINS0_4http8ResponseEEEvEZZNKS0_9_DeferredIZZNS0_11ProcessBase6_visitERKNS7_12HttpEndpointERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEERKNS0_5OwnedINS2_7RequestNKUlRK6OptionINS2_14authentication20AuthenticationResultEEE0_clEST_EUlbE1_EcvSt8functionIFT_T0_EEIS4_RKbEEvENKUlS14_E_clES14_EUlvE_E9_M_invokeERKSt9_Any_data
@ 0x7efebb5ce8ca std::function<>::operator()()
@ 0x7efebb5c4b27
_ZZN7process8internal8DispatchINS_6FutureINS_4http8ResponseclIRSt8functionIFS5_vS5_RKNS_4UPIDEOT_ENKUlPNS_11ProcessBaseEE_clESI_
@ 0x7efebb5d4e1e
_ZNSt17_Function_handlerIFvPN7process11ProcessBaseEEZNS0_8internal8DispatchINS0_6FutureINS0_4http8ResponseclIRSt8functionIFS9_vS9_RKNS0_4UPIDEOT_EUlS2_E_E9_M_invokeERKSt9_Any_dataOS2_
@ 0x7efebcb30baf std::function<>::operator()()
@ 0x7efebcb13fd6 process::ProcessBase::visit()
@ 0x7efebcb1f3c8 process::DispatchEvent::visit()
@ 0x7efebb3ab2ea process::ProcessBase::serve()
@ 0x7efebcb0fe8a process::ProcessManager::resume()
@ 0x7efebcb0c5a3 _ZZN7process14ProcessManager12init_threadsEvENKUt_clEv
@ 0x7efebcb1ea34
_ZNSt12_Bind_simpleIFZN7process14ProcessManager12init_threadsEvEUt_vEE9_M_invokeIJEEEvSt12_Index_tupleIJXspT_EEE
@ 0x7efebcb1e98a
_ZNSt12_Bind_simpleIFZN7process14ProcessManager12init_threadsEvEUt_vEEclEv
@ 0x7efebcb1e91a
_ZNSt6thread5_ImplISt12_Bind_simpleIFZN7process14ProcessManager12init_threadsEvEUt_vEEE6_M_runEv
@ 0x7efeb6980c80 (unknown)
@ 0x7efeb649c6ba start_thread
@ 0x7efeb61d282d (unknown)
Aborted (core dumped)
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-6909) ABORT execvpe() crash when binaries from launcher_dir cannot be found
[
https://issues.apache.org/jira/browse/MESOS-6909?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15819100#comment-15819100
]
Aaron Wood commented on MESOS-6909:
---
No problem! :)
> ABORT execvpe() crash when binaries from launcher_dir cannot be found
> -
>
> Key: MESOS-6909
> URL: https://issues.apache.org/jira/browse/MESOS-6909
> Project: Mesos
> Issue Type: Bug
> Components: agent
>Affects Versions: 1.1.0
>Reporter: Aaron Wood
>Assignee: Kevin Klues
>
> When running the Mesos agent either without --launcher_dir or with a
> --launcher_dir not pointing to the right place tasks are launched you'll get
> a crash:
> {code}
> E0111 10:50:56.665149 20924 slave.cpp:4423] Container
> '6cdd0c9b-cb29-42b0-b6cf-51f410df0f31' for executor
> '99D50FCB-ADB0-6B2A-3FC3-8A47FF178C10' of framework
> d3bc8031-29b6-4c2f-9fe3-a73c1b8b6360-0007 failed to start: Collect failed:
> Failed to setup hostname and network files: ABORT:
> (../../../3rdparty/libprocess/include/process/posix/subprocess.hpp:214):
> Failed to os::execvpe on path '/usr/local/libexec/mesos/mesos-containerizer':
> No such file or directory
> Aborted at 1484149856 (unix time) try "date -d @1484149856" if you are using
> GNU date ***
> PC: @ 0x7fc3bd418428 (unknown)
> SIGABRT (@0x51d8) received by PID 20952 (TID 0x7fc3b6007700) from PID 20952;
> stack trace: ***
> @ 0x7fc3bd7bd390 (unknown)
> @ 0x7fc3bd418428 (unknown)
> @ 0x7fc3bd41a02a (unknown)
> @ 0x47fafc _Abort()
> @ 0x47fb2a _Abort()
> @ 0x7fc3c385f092 process::internal::childMain()
> @ 0x7fc3c3864227
> _ZNSt5_BindIFPFiRKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEPPcS9_RKN7process10Subprocess2IO20InputFileDescriptorsERKNSC_21OutputFileDescriptorsESI_bPiRKSt6vectorINSB_9ChildHookESaISL_EEES5_S9_S9_SD_SG_SG_bSJ_SN_EE6__callIiJEJLm0ELm1ELm2ELm3ELm4ELm5ELm6ELm7ELm8T_OSt5tupleIJDpT0_EESt12_Index_tupleIJXspT1_EEE
> @ 0x7fc3c38635d3 std::_Bind<>::operator()<>()
> @ 0x7fc3c3862682 std::_Function_handler<>::_M_invoke()
> @ 0x48a4b8 std::function<>::operator()()
> @ 0x7fc3c247de67 process::defaultClone()
> @ 0x7fc3c3861c40 std::_Function_handler<>::_M_invoke()
> @ 0x7fc3c3861411 std::function<>::operator()()
> @ 0x7fc3c385f8f5 process::internal::cloneChild()
> @ 0x7fc3c385d50e process::subprocess()
> @ 0x7fc3c30d318f
> mesos::internal::slave::NetworkCniIsolatorProcess::__isolate()
> @ 0x7fc3c30cf909
> mesos::internal::slave::NetworkCniIsolatorProcess::isolate()
> @ 0x7fc3c2d4db56
> _ZZN7process8dispatchI7NothingN5mesos8internal5slave20MesosIsolatorProcessERKNS2_11ContainerIDEiS6_iEENS_6FutureIT_EERKNS_3PIDIT0_EEMSD_FSB_T1_T2_ET3_T4_ENKUlPNS_11ProcessBaseEE_clESO_
> @ 0x7fc3c2d50eb8
> _ZNSt17_Function_handlerIFvPN7process11ProcessBaseEEZNS0_8dispatchI7NothingN5mesos8internal5slave20MesosIsolatorProcessERKNS6_11ContainerIDEiSA_iEENS0_6FutureIT_EERKNS0_3PIDIT0_EEMSH_FSF_T1_T2_ET3_T4_EUlS2_E_E9_M_invokeERKSt9_Any_dataOS2_
> @ 0x7fc3c380a1dd std::function<>::operator()()
> @ 0x7fc3c37eb094 process::ProcessBase::visit()
> @ 0x7fc3c37f3b26 process::DispatchEvent::visit()
> @ 0x7fc3c2244a08 process::ProcessBase::serve()
> @ 0x7fc3c37e6f50 process::ProcessManager::resume()
> @ 0x7fc3c37e3a78
> _ZZN7process14ProcessManager12init_threadsEvENKUt_clEv
> @ 0x7fc3c37f3148
> _ZNSt12_Bind_simpleIFZN7process14ProcessManager12init_threadsEvEUt_vEE9_M_invokeIJEEEvSt12_Index_tupleIJXspT_EEE
> @ 0x7fc3c37f309e
> _ZNSt12_Bind_simpleIFZN7process14ProcessManager12init_threadsEvEUt_vEEclEv
> @ 0x7fc3c37f302e
> _ZNSt6thread5_ImplISt12_Bind_simpleIFZN7process14ProcessManager12init_threadsEvEUt_vEEE6_M_runEv
> @ 0x7fc3bdc97c80 (unknown)
> @ 0x7fc3bd7b36ba start_thread
> @ 0x7fc3bd4e982d (unknown)
> {code}
> Note that this does not crash hard so the agent stays running.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MESOS-6910) Segfault when running agent on anything other than Linux while using unified containerizer
[
https://issues.apache.org/jira/browse/MESOS-6910?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aaron Wood updated MESOS-6910:
--
Description:
When running the Mesos agent on OS X ([~hausdorff] not sure if this applies to
Windows or not) and using the unified containerizer the agent will segfault:
{code}
WARNING: Logging before InitGoogleLogging() is written to STDERR
I0110 12:45:56.882041 2100015104 main.cpp:243] Build: 2016-11-16 18:56:50 by
brew
I0110 12:45:56.883872 2100015104 main.cpp:244] Version: 1.1.0
I0110 12:45:56.887733 2100015104 containerizer.cpp:200] Using isolation:
docker/runtime,filesystem/posix
Aborted at 1484070356 (unix time) try "date -d @1484070356" if you are using
GNU date ***
PC: @0x10b5049ca std::__1::__tree<>::__assign_multi<>()
SIGSEGV (@0x0) received by PID 47147 (TID 0x7fff7d2bb000) stack trace: ***
@ 0x7fff899b252a _sigtramp
@ 0x7feea043f870 (unknown)
@0x10b50496c flags::FlagsBase::operator=()
@0x10b503924 mesos::uri::fetcher::Flags::operator=()
@0x10b502902 mesos::uri::fetcher::create()
@0x10b4eefd3 mesos::internal::slave::docker::Store::create()
@0x10b4b241f mesos::internal::slave::Store::create()
@0x10b49925a mesos::internal::slave::Provisioner::create()
@0x10b40cc6f mesos::internal::slave::MesosContainerizer::create()
@0x10b3ab426 mesos::internal::slave::Containerizer::create()
@0x10af20d80 main
@ 0x7fff9a3995ad start
@0x6 (unknown)
Segmentation fault: 11
{code}
To reproduce this you can run:
mesos-slave --master=127.0.0.1:5050 --work_dir=/tmp/slave
--containerizers=mesos --image_providers=docker --isolation=docker/runtime
was:
When running the Mesos agent on OS X ([~hausdorff] not sure if this applies to
Windows or not) and using the unified containerizer the agent will segfault:
WARNING: Logging before InitGoogleLogging() is written to STDERR
I0110 12:45:56.882041 2100015104 main.cpp:243] Build: 2016-11-16 18:56:50 by
brew
I0110 12:45:56.883872 2100015104 main.cpp:244] Version: 1.1.0
I0110 12:45:56.887733 2100015104 containerizer.cpp:200] Using isolation:
docker/runtime,filesystem/posix
Aborted at 1484070356 (unix time) try "date -d @1484070356" if you are using
GNU date ***
PC: @0x10b5049ca std::__1::__tree<>::__assign_multi<>()
SIGSEGV (@0x0) received by PID 47147 (TID 0x7fff7d2bb000) stack trace: ***
@ 0x7fff899b252a _sigtramp
@ 0x7feea043f870 (unknown)
@0x10b50496c flags::FlagsBase::operator=()
@0x10b503924 mesos::uri::fetcher::Flags::operator=()
@0x10b502902 mesos::uri::fetcher::create()
@0x10b4eefd3 mesos::internal::slave::docker::Store::create()
@0x10b4b241f mesos::internal::slave::Store::create()
@0x10b49925a mesos::internal::slave::Provisioner::create()
@0x10b40cc6f mesos::internal::slave::MesosContainerizer::create()
@0x10b3ab426 mesos::internal::slave::Containerizer::create()
@0x10af20d80 main
@ 0x7fff9a3995ad start
@0x6 (unknown)
Segmentation fault: 11
To reproduce this you can run:
mesos-slave --master=127.0.0.1:5050 --work_dir=/tmp/slave
--containerizers=mesos --image_providers=docker --isolation=docker/runtime
> Segfault when running agent on anything other than Linux while using unified
> containerizer
> --
>
> Key: MESOS-6910
> URL: https://issues.apache.org/jira/browse/MESOS-6910
> Project: Mesos
> Issue Type: Bug
> Components: agent, containerization, isolation
>Affects Versions: 1.1.0
>Reporter: Aaron Wood
>
> When running the Mesos agent on OS X ([~hausdorff] not sure if this applies
> to Windows or not) and using the unified containerizer the agent will
> segfault:
> {code}
> WARNING: Logging before InitGoogleLogging() is written to STDERR
> I0110 12:45:56.882041 2100015104 main.cpp:243] Build: 2016-11-16 18:56:50 by
> brew
> I0110 12:45:56.883872 2100015104 main.cpp:244] Version: 1.1.0
> I0110 12:45:56.887733 2100015104 containerizer.cpp:200] Using isolation:
> docker/runtime,filesystem/posix
> Aborted at 1484070356 (unix time) try "date -d @1484070356" if you are using
> GNU date ***
> PC: @0x10b5049ca std::__1::__tree<>::__assign_multi<>()
> SIGSEGV (@0x0) received by PID 47147 (TID 0x7fff7d2bb000) stack trace: ***
> @ 0x7fff899b252a _sigtramp
> @ 0x7feea043f870 (unknown)
> @0x10b50496c flags::FlagsBase::operator=()
> @0x10b503924 mesos::uri::fetcher::Flags::operator=()
> @0x10b502902 mesos::uri::fetcher::create()
> @0x10b4eefd3 mesos::internal::slave::docker::Store::create()
> @0x10b4b241f
[jira] [Commented] (MESOS-6910) Segfault when running agent on anything other than Linux while using unified containerizer
[ https://issues.apache.org/jira/browse/MESOS-6910?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15818745#comment-15818745 ] Aaron Wood commented on MESOS-6910: --- In this case I believe I am (using Mesos from brew). [~jieyu] had said he wanted to get this fixed so I thought that someone would want to add a check for these cases at build time or something. > Segfault when running agent on anything other than Linux while using unified > containerizer > -- > > Key: MESOS-6910 > URL: https://issues.apache.org/jira/browse/MESOS-6910 > Project: Mesos > Issue Type: Bug > Components: agent, containerization, isolation >Affects Versions: 1.1.0 >Reporter: Aaron Wood > > When running the Mesos agent on OS X ([~hausdorff] not sure if this applies > to Windows or not) and using the unified containerizer the agent will > segfault: > WARNING: Logging before InitGoogleLogging() is written to STDERR > I0110 12:45:56.882041 2100015104 main.cpp:243] Build: 2016-11-16 18:56:50 by > brew > I0110 12:45:56.883872 2100015104 main.cpp:244] Version: 1.1.0 > I0110 12:45:56.887733 2100015104 containerizer.cpp:200] Using isolation: > docker/runtime,filesystem/posix > Aborted at 1484070356 (unix time) try "date -d @1484070356" if you are using > GNU date *** > PC: @0x10b5049ca std::__1::__tree<>::__assign_multi<>() > SIGSEGV (@0x0) received by PID 47147 (TID 0x7fff7d2bb000) stack trace: *** > @ 0x7fff899b252a _sigtramp > @ 0x7feea043f870 (unknown) > @0x10b50496c flags::FlagsBase::operator=() > @0x10b503924 mesos::uri::fetcher::Flags::operator=() > @0x10b502902 mesos::uri::fetcher::create() > @0x10b4eefd3 mesos::internal::slave::docker::Store::create() > @0x10b4b241f mesos::internal::slave::Store::create() > @0x10b49925a mesos::internal::slave::Provisioner::create() > @0x10b40cc6f mesos::internal::slave::MesosContainerizer::create() > @0x10b3ab426 mesos::internal::slave::Containerizer::create() > @0x10af20d80 main > @ 0x7fff9a3995ad start > @0x6 (unknown) > Segmentation fault: 11 > To reproduce this you can run: > mesos-slave --master=127.0.0.1:5050 --work_dir=/tmp/slave > --containerizers=mesos --image_providers=docker --isolation=docker/runtime -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-6910) Segfault when running agent on anything other than Linux while using unified containerizer
[ https://issues.apache.org/jira/browse/MESOS-6910?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aaron Wood updated MESOS-6910: -- Summary: Segfault when running agent on anything other than Linux while using unified containerizer (was: Sefault when running agent on anything other than Linux while using unified containerizer) > Segfault when running agent on anything other than Linux while using unified > containerizer > -- > > Key: MESOS-6910 > URL: https://issues.apache.org/jira/browse/MESOS-6910 > Project: Mesos > Issue Type: Bug > Components: agent, containerization, isolation >Affects Versions: 1.1.0 >Reporter: Aaron Wood > > When running the Mesos agent on OS X ([~hausdorff] not sure if this applies > to Windows or not) and using the unified containerizer the agent will > segfault: > WARNING: Logging before InitGoogleLogging() is written to STDERR > I0110 12:45:56.882041 2100015104 main.cpp:243] Build: 2016-11-16 18:56:50 by > brew > I0110 12:45:56.883872 2100015104 main.cpp:244] Version: 1.1.0 > I0110 12:45:56.887733 2100015104 containerizer.cpp:200] Using isolation: > docker/runtime,filesystem/posix > Aborted at 1484070356 (unix time) try "date -d @1484070356" if you are using > GNU date *** > PC: @0x10b5049ca std::__1::__tree<>::__assign_multi<>() > SIGSEGV (@0x0) received by PID 47147 (TID 0x7fff7d2bb000) stack trace: *** > @ 0x7fff899b252a _sigtramp > @ 0x7feea043f870 (unknown) > @0x10b50496c flags::FlagsBase::operator=() > @0x10b503924 mesos::uri::fetcher::Flags::operator=() > @0x10b502902 mesos::uri::fetcher::create() > @0x10b4eefd3 mesos::internal::slave::docker::Store::create() > @0x10b4b241f mesos::internal::slave::Store::create() > @0x10b49925a mesos::internal::slave::Provisioner::create() > @0x10b40cc6f mesos::internal::slave::MesosContainerizer::create() > @0x10b3ab426 mesos::internal::slave::Containerizer::create() > @0x10af20d80 main > @ 0x7fff9a3995ad start > @0x6 (unknown) > Segmentation fault: 11 > To reproduce this you can run: > mesos-slave --master=127.0.0.1:5050 --work_dir=/tmp/slave > --containerizers=mesos --image_providers=docker --isolation=docker/runtime -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-6910) Sefault when running agent on anything other than Linux while using unified containerizer
[ https://issues.apache.org/jira/browse/MESOS-6910?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aaron Wood updated MESOS-6910: -- Description: When running the Mesos agent on OS X ([~hausdorff] not sure if this applies to Windows) and using the unified containerizer the agent will segfault: WARNING: Logging before InitGoogleLogging() is written to STDERR I0110 12:45:56.882041 2100015104 main.cpp:243] Build: 2016-11-16 18:56:50 by brew I0110 12:45:56.883872 2100015104 main.cpp:244] Version: 1.1.0 I0110 12:45:56.887733 2100015104 containerizer.cpp:200] Using isolation: docker/runtime,filesystem/posix Aborted at 1484070356 (unix time) try "date -d @1484070356" if you are using GNU date *** PC: @0x10b5049ca std::__1::__tree<>::__assign_multi<>() SIGSEGV (@0x0) received by PID 47147 (TID 0x7fff7d2bb000) stack trace: *** @ 0x7fff899b252a _sigtramp @ 0x7feea043f870 (unknown) @0x10b50496c flags::FlagsBase::operator=() @0x10b503924 mesos::uri::fetcher::Flags::operator=() @0x10b502902 mesos::uri::fetcher::create() @0x10b4eefd3 mesos::internal::slave::docker::Store::create() @0x10b4b241f mesos::internal::slave::Store::create() @0x10b49925a mesos::internal::slave::Provisioner::create() @0x10b40cc6f mesos::internal::slave::MesosContainerizer::create() @0x10b3ab426 mesos::internal::slave::Containerizer::create() @0x10af20d80 main @ 0x7fff9a3995ad start @0x6 (unknown) Segmentation fault: 11 To reproduce this you can run: mesos-slave --master=127.0.0.1:5050 --work_dir=/tmp/slave --containerizers=mesos --image_providers=docker --isolation=docker/runtime was: When running the Mesos agent on OS X ([~hausdorff] not sure if this applies to Windows) and using the unified containerizer the agent will segfault: WARNING: Logging before InitGoogleLogging() is written to STDERR I0110 12:45:56.882041 2100015104 main.cpp:243] Build: 2016-11-16 18:56:50 by brew I0110 12:45:56.883872 2100015104 main.cpp:244] Version: 1.1.0 I0110 12:45:56.887733 2100015104 containerizer.cpp:200] Using isolation: docker/runtime,filesystem/posix *** Aborted at 1484070356 (unix time) try "date -d @1484070356" if you are using GNU date *** PC: @0x10b5049ca std::__1::__tree<>::__assign_multi<>() *** SIGSEGV (@0x0) received by PID 47147 (TID 0x7fff7d2bb000) stack trace: *** @ 0x7fff899b252a _sigtramp @ 0x7feea043f870 (unknown) @0x10b50496c flags::FlagsBase::operator=() @0x10b503924 mesos::uri::fetcher::Flags::operator=() @0x10b502902 mesos::uri::fetcher::create() @0x10b4eefd3 mesos::internal::slave::docker::Store::create() @0x10b4b241f mesos::internal::slave::Store::create() @0x10b49925a mesos::internal::slave::Provisioner::create() @0x10b40cc6f mesos::internal::slave::MesosContainerizer::create() @0x10b3ab426 mesos::internal::slave::Containerizer::create() @0x10af20d80 main @ 0x7fff9a3995ad start @0x6 (unknown) Segmentation fault: 11 To reproduce this you can run: mesos-slave --master=127.0.0.1:5050 --work_dir=/tmp/slave --containerizers=mesos --image_providers=docker --isolation=docker/runtime > Sefault when running agent on anything other than Linux while using unified > containerizer > - > > Key: MESOS-6910 > URL: https://issues.apache.org/jira/browse/MESOS-6910 > Project: Mesos > Issue Type: Bug > Components: agent, containerization, isolation >Affects Versions: 1.1.0 >Reporter: Aaron Wood > > When running the Mesos agent on OS X ([~hausdorff] not sure if this applies > to Windows) and using the unified containerizer the agent will segfault: > WARNING: Logging before InitGoogleLogging() is written to STDERR > I0110 12:45:56.882041 2100015104 main.cpp:243] Build: 2016-11-16 18:56:50 by > brew > I0110 12:45:56.883872 2100015104 main.cpp:244] Version: 1.1.0 > I0110 12:45:56.887733 2100015104 containerizer.cpp:200] Using isolation: > docker/runtime,filesystem/posix > Aborted at 1484070356 (unix time) try "date -d @1484070356" if you are using > GNU date *** > PC: @0x10b5049ca std::__1::__tree<>::__assign_multi<>() > SIGSEGV (@0x0) received by PID 47147 (TID 0x7fff7d2bb000) stack trace: *** > @ 0x7fff899b252a _sigtramp > @ 0x7feea043f870 (unknown) > @0x10b50496c flags::FlagsBase::operator=() > @0x10b503924 mesos::uri::fetcher::Flags::operator=() > @0x10b502902 mesos::uri::fetcher::create() > @0x10b4eefd3 mesos::internal::slave::docker::Store::create() > @0x10b4b241f mesos::internal::slave::Store::create() >
[jira] [Created] (MESOS-6910) Sefault when running agent on anything other than Linux while using unified containerizer
Aaron Wood created MESOS-6910: - Summary: Sefault when running agent on anything other than Linux while using unified containerizer Key: MESOS-6910 URL: https://issues.apache.org/jira/browse/MESOS-6910 Project: Mesos Issue Type: Bug Components: agent, containerization, isolation Affects Versions: 1.1.0 Reporter: Aaron Wood When running the Mesos agent on OS X ([~hausdorff] not sure if this applies to Windows) and using the unified containerizer the agent will segfault: WARNING: Logging before InitGoogleLogging() is written to STDERR I0110 12:45:56.882041 2100015104 main.cpp:243] Build: 2016-11-16 18:56:50 by brew I0110 12:45:56.883872 2100015104 main.cpp:244] Version: 1.1.0 I0110 12:45:56.887733 2100015104 containerizer.cpp:200] Using isolation: docker/runtime,filesystem/posix *** Aborted at 1484070356 (unix time) try "date -d @1484070356" if you are using GNU date *** PC: @0x10b5049ca std::__1::__tree<>::__assign_multi<>() *** SIGSEGV (@0x0) received by PID 47147 (TID 0x7fff7d2bb000) stack trace: *** @ 0x7fff899b252a _sigtramp @ 0x7feea043f870 (unknown) @0x10b50496c flags::FlagsBase::operator=() @0x10b503924 mesos::uri::fetcher::Flags::operator=() @0x10b502902 mesos::uri::fetcher::create() @0x10b4eefd3 mesos::internal::slave::docker::Store::create() @0x10b4b241f mesos::internal::slave::Store::create() @0x10b49925a mesos::internal::slave::Provisioner::create() @0x10b40cc6f mesos::internal::slave::MesosContainerizer::create() @0x10b3ab426 mesos::internal::slave::Containerizer::create() @0x10af20d80 main @ 0x7fff9a3995ad start @0x6 (unknown) Segmentation fault: 11 To reproduce this you can run: mesos-slave --master=127.0.0.1:5050 --work_dir=/tmp/slave --containerizers=mesos --image_providers=docker --isolation=docker/runtime -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-6910) Sefault when running agent on anything other than Linux while using unified containerizer
[ https://issues.apache.org/jira/browse/MESOS-6910?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aaron Wood updated MESOS-6910: -- Description: When running the Mesos agent on OS X ([~hausdorff] not sure if this applies to Windows or not) and using the unified containerizer the agent will segfault: WARNING: Logging before InitGoogleLogging() is written to STDERR I0110 12:45:56.882041 2100015104 main.cpp:243] Build: 2016-11-16 18:56:50 by brew I0110 12:45:56.883872 2100015104 main.cpp:244] Version: 1.1.0 I0110 12:45:56.887733 2100015104 containerizer.cpp:200] Using isolation: docker/runtime,filesystem/posix Aborted at 1484070356 (unix time) try "date -d @1484070356" if you are using GNU date *** PC: @0x10b5049ca std::__1::__tree<>::__assign_multi<>() SIGSEGV (@0x0) received by PID 47147 (TID 0x7fff7d2bb000) stack trace: *** @ 0x7fff899b252a _sigtramp @ 0x7feea043f870 (unknown) @0x10b50496c flags::FlagsBase::operator=() @0x10b503924 mesos::uri::fetcher::Flags::operator=() @0x10b502902 mesos::uri::fetcher::create() @0x10b4eefd3 mesos::internal::slave::docker::Store::create() @0x10b4b241f mesos::internal::slave::Store::create() @0x10b49925a mesos::internal::slave::Provisioner::create() @0x10b40cc6f mesos::internal::slave::MesosContainerizer::create() @0x10b3ab426 mesos::internal::slave::Containerizer::create() @0x10af20d80 main @ 0x7fff9a3995ad start @0x6 (unknown) Segmentation fault: 11 To reproduce this you can run: mesos-slave --master=127.0.0.1:5050 --work_dir=/tmp/slave --containerizers=mesos --image_providers=docker --isolation=docker/runtime was: When running the Mesos agent on OS X ([~hausdorff] not sure if this applies to Windows) and using the unified containerizer the agent will segfault: WARNING: Logging before InitGoogleLogging() is written to STDERR I0110 12:45:56.882041 2100015104 main.cpp:243] Build: 2016-11-16 18:56:50 by brew I0110 12:45:56.883872 2100015104 main.cpp:244] Version: 1.1.0 I0110 12:45:56.887733 2100015104 containerizer.cpp:200] Using isolation: docker/runtime,filesystem/posix Aborted at 1484070356 (unix time) try "date -d @1484070356" if you are using GNU date *** PC: @0x10b5049ca std::__1::__tree<>::__assign_multi<>() SIGSEGV (@0x0) received by PID 47147 (TID 0x7fff7d2bb000) stack trace: *** @ 0x7fff899b252a _sigtramp @ 0x7feea043f870 (unknown) @0x10b50496c flags::FlagsBase::operator=() @0x10b503924 mesos::uri::fetcher::Flags::operator=() @0x10b502902 mesos::uri::fetcher::create() @0x10b4eefd3 mesos::internal::slave::docker::Store::create() @0x10b4b241f mesos::internal::slave::Store::create() @0x10b49925a mesos::internal::slave::Provisioner::create() @0x10b40cc6f mesos::internal::slave::MesosContainerizer::create() @0x10b3ab426 mesos::internal::slave::Containerizer::create() @0x10af20d80 main @ 0x7fff9a3995ad start @0x6 (unknown) Segmentation fault: 11 To reproduce this you can run: mesos-slave --master=127.0.0.1:5050 --work_dir=/tmp/slave --containerizers=mesos --image_providers=docker --isolation=docker/runtime > Sefault when running agent on anything other than Linux while using unified > containerizer > - > > Key: MESOS-6910 > URL: https://issues.apache.org/jira/browse/MESOS-6910 > Project: Mesos > Issue Type: Bug > Components: agent, containerization, isolation >Affects Versions: 1.1.0 >Reporter: Aaron Wood > > When running the Mesos agent on OS X ([~hausdorff] not sure if this applies > to Windows or not) and using the unified containerizer the agent will > segfault: > WARNING: Logging before InitGoogleLogging() is written to STDERR > I0110 12:45:56.882041 2100015104 main.cpp:243] Build: 2016-11-16 18:56:50 by > brew > I0110 12:45:56.883872 2100015104 main.cpp:244] Version: 1.1.0 > I0110 12:45:56.887733 2100015104 containerizer.cpp:200] Using isolation: > docker/runtime,filesystem/posix > Aborted at 1484070356 (unix time) try "date -d @1484070356" if you are using > GNU date *** > PC: @0x10b5049ca std::__1::__tree<>::__assign_multi<>() > SIGSEGV (@0x0) received by PID 47147 (TID 0x7fff7d2bb000) stack trace: *** > @ 0x7fff899b252a _sigtramp > @ 0x7feea043f870 (unknown) > @0x10b50496c flags::FlagsBase::operator=() > @0x10b503924 mesos::uri::fetcher::Flags::operator=() > @0x10b502902 mesos::uri::fetcher::create() > @0x10b4eefd3 mesos::internal::slave::docker::Store::create() > @0x10b4b241f
[jira] [Updated] (MESOS-6909) ABORT execvpe() crash when binaries from launcher_dir cannot be found
[ https://issues.apache.org/jira/browse/MESOS-6909?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aaron Wood updated MESOS-6909: -- Description: When running the Mesos agent either without --launcher_dir or with a --launcher_dir not pointing to the right place tasks are launched you'll get a crash: E0111 10:50:56.665149 20924 slave.cpp:4423] Container '6cdd0c9b-cb29-42b0-b6cf-51f410df0f31' for executor '99D50FCB-ADB0-6B2A-3FC3-8A47FF178C10' of framework d3bc8031-29b6-4c2f-9fe3-a73c1b8b6360-0007 failed to start: Collect failed: Failed to setup hostname and network files: ABORT: (../../../3rdparty/libprocess/include/process/posix/subprocess.hpp:214): Failed to os::execvpe on path '/usr/local/libexec/mesos/mesos-containerizer': No such file or directory Aborted at 1484149856 (unix time) try "date -d @1484149856" if you are using GNU date *** PC: @ 0x7fc3bd418428 (unknown) SIGABRT (@0x51d8) received by PID 20952 (TID 0x7fc3b6007700) from PID 20952; stack trace: *** @ 0x7fc3bd7bd390 (unknown) @ 0x7fc3bd418428 (unknown) @ 0x7fc3bd41a02a (unknown) @ 0x47fafc _Abort() @ 0x47fb2a _Abort() @ 0x7fc3c385f092 process::internal::childMain() @ 0x7fc3c3864227 _ZNSt5_BindIFPFiRKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEPPcS9_RKN7process10Subprocess2IO20InputFileDescriptorsERKNSC_21OutputFileDescriptorsESI_bPiRKSt6vectorINSB_9ChildHookESaISL_EEES5_S9_S9_SD_SG_SG_bSJ_SN_EE6__callIiJEJLm0ELm1ELm2ELm3ELm4ELm5ELm6ELm7ELm8T_OSt5tupleIJDpT0_EESt12_Index_tupleIJXspT1_EEE @ 0x7fc3c38635d3 std::_Bind<>::operator()<>() @ 0x7fc3c3862682 std::_Function_handler<>::_M_invoke() @ 0x48a4b8 std::function<>::operator()() @ 0x7fc3c247de67 process::defaultClone() @ 0x7fc3c3861c40 std::_Function_handler<>::_M_invoke() @ 0x7fc3c3861411 std::function<>::operator()() @ 0x7fc3c385f8f5 process::internal::cloneChild() @ 0x7fc3c385d50e process::subprocess() @ 0x7fc3c30d318f mesos::internal::slave::NetworkCniIsolatorProcess::__isolate() @ 0x7fc3c30cf909 mesos::internal::slave::NetworkCniIsolatorProcess::isolate() @ 0x7fc3c2d4db56 _ZZN7process8dispatchI7NothingN5mesos8internal5slave20MesosIsolatorProcessERKNS2_11ContainerIDEiS6_iEENS_6FutureIT_EERKNS_3PIDIT0_EEMSD_FSB_T1_T2_ET3_T4_ENKUlPNS_11ProcessBaseEE_clESO_ @ 0x7fc3c2d50eb8 _ZNSt17_Function_handlerIFvPN7process11ProcessBaseEEZNS0_8dispatchI7NothingN5mesos8internal5slave20MesosIsolatorProcessERKNS6_11ContainerIDEiSA_iEENS0_6FutureIT_EERKNS0_3PIDIT0_EEMSH_FSF_T1_T2_ET3_T4_EUlS2_E_E9_M_invokeERKSt9_Any_dataOS2_ @ 0x7fc3c380a1dd std::function<>::operator()() @ 0x7fc3c37eb094 process::ProcessBase::visit() @ 0x7fc3c37f3b26 process::DispatchEvent::visit() @ 0x7fc3c2244a08 process::ProcessBase::serve() @ 0x7fc3c37e6f50 process::ProcessManager::resume() @ 0x7fc3c37e3a78 _ZZN7process14ProcessManager12init_threadsEvENKUt_clEv @ 0x7fc3c37f3148 _ZNSt12_Bind_simpleIFZN7process14ProcessManager12init_threadsEvEUt_vEE9_M_invokeIJEEEvSt12_Index_tupleIJXspT_EEE @ 0x7fc3c37f309e _ZNSt12_Bind_simpleIFZN7process14ProcessManager12init_threadsEvEUt_vEEclEv @ 0x7fc3c37f302e _ZNSt6thread5_ImplISt12_Bind_simpleIFZN7process14ProcessManager12init_threadsEvEUt_vEEE6_M_runEv @ 0x7fc3bdc97c80 (unknown) @ 0x7fc3bd7b36ba start_thread @ 0x7fc3bd4e982d (unknown) Note that this does not crash hard so the agent stays running. was: When running the Mesos agent either without --launcher_dir or with a --launcher_dir not pointing to the right place tasks are launched you'll get a crash: E0111 10:50:56.665149 20924 slave.cpp:4423] Container '6cdd0c9b-cb29-42b0-b6cf-51f410df0f31' for executor '99D50FCB-ADB0-6B2A-3FC3-8A47FF178C10' of framework d3bc8031-29b6-4c2f-9fe3-a73c1b8b6360-0007 failed to start: Collect failed: Failed to setup hostname and network files: ABORT: (../../../3rdparty/libprocess/include/process/posix/subprocess.hpp:214): Failed to os::execvpe on path '/usr/local/libexec/mesos/mesos-containerizer': No such file or directory *** Aborted at 1484149856 (unix time) try "date -d @1484149856" if you are using GNU date *** PC: @ 0x7fc3bd418428 (unknown) *** SIGABRT (@0x51d8) received by PID 20952 (TID 0x7fc3b6007700) from PID 20952; stack trace: *** @ 0x7fc3bd7bd390 (unknown) @ 0x7fc3bd418428 (unknown) @ 0x7fc3bd41a02a (unknown) @ 0x47fafc _Abort() @ 0x47fb2a _Abort() @ 0x7fc3c385f092 process::internal::childMain() @ 0x7fc3c3864227
[jira] [Created] (MESOS-6909) ABORT execvpe() crash when binaries from launcher_dir cannot be found
Aaron Wood created MESOS-6909: - Summary: ABORT execvpe() crash when binaries from launcher_dir cannot be found Key: MESOS-6909 URL: https://issues.apache.org/jira/browse/MESOS-6909 Project: Mesos Issue Type: Bug Components: agent Affects Versions: 1.1.0 Reporter: Aaron Wood When running the Mesos agent either without --launcher_dir or with a --launcher_dir not pointing to the right place tasks are launched you'll get a crash: E0111 10:50:56.665149 20924 slave.cpp:4423] Container '6cdd0c9b-cb29-42b0-b6cf-51f410df0f31' for executor '99D50FCB-ADB0-6B2A-3FC3-8A47FF178C10' of framework d3bc8031-29b6-4c2f-9fe3-a73c1b8b6360-0007 failed to start: Collect failed: Failed to setup hostname and network files: ABORT: (../../../3rdparty/libprocess/include/process/posix/subprocess.hpp:214): Failed to os::execvpe on path '/usr/local/libexec/mesos/mesos-containerizer': No such file or directory *** Aborted at 1484149856 (unix time) try "date -d @1484149856" if you are using GNU date *** PC: @ 0x7fc3bd418428 (unknown) *** SIGABRT (@0x51d8) received by PID 20952 (TID 0x7fc3b6007700) from PID 20952; stack trace: *** @ 0x7fc3bd7bd390 (unknown) @ 0x7fc3bd418428 (unknown) @ 0x7fc3bd41a02a (unknown) @ 0x47fafc _Abort() @ 0x47fb2a _Abort() @ 0x7fc3c385f092 process::internal::childMain() @ 0x7fc3c3864227 _ZNSt5_BindIFPFiRKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEPPcS9_RKN7process10Subprocess2IO20InputFileDescriptorsERKNSC_21OutputFileDescriptorsESI_bPiRKSt6vectorINSB_9ChildHookESaISL_EEES5_S9_S9_SD_SG_SG_bSJ_SN_EE6__callIiJEJLm0ELm1ELm2ELm3ELm4ELm5ELm6ELm7ELm8T_OSt5tupleIJDpT0_EESt12_Index_tupleIJXspT1_EEE @ 0x7fc3c38635d3 std::_Bind<>::operator()<>() @ 0x7fc3c3862682 std::_Function_handler<>::_M_invoke() @ 0x48a4b8 std::function<>::operator()() @ 0x7fc3c247de67 process::defaultClone() @ 0x7fc3c3861c40 std::_Function_handler<>::_M_invoke() @ 0x7fc3c3861411 std::function<>::operator()() @ 0x7fc3c385f8f5 process::internal::cloneChild() @ 0x7fc3c385d50e process::subprocess() @ 0x7fc3c30d318f mesos::internal::slave::NetworkCniIsolatorProcess::__isolate() @ 0x7fc3c30cf909 mesos::internal::slave::NetworkCniIsolatorProcess::isolate() @ 0x7fc3c2d4db56 _ZZN7process8dispatchI7NothingN5mesos8internal5slave20MesosIsolatorProcessERKNS2_11ContainerIDEiS6_iEENS_6FutureIT_EERKNS_3PIDIT0_EEMSD_FSB_T1_T2_ET3_T4_ENKUlPNS_11ProcessBaseEE_clESO_ @ 0x7fc3c2d50eb8 _ZNSt17_Function_handlerIFvPN7process11ProcessBaseEEZNS0_8dispatchI7NothingN5mesos8internal5slave20MesosIsolatorProcessERKNS6_11ContainerIDEiSA_iEENS0_6FutureIT_EERKNS0_3PIDIT0_EEMSH_FSF_T1_T2_ET3_T4_EUlS2_E_E9_M_invokeERKSt9_Any_dataOS2_ @ 0x7fc3c380a1dd std::function<>::operator()() @ 0x7fc3c37eb094 process::ProcessBase::visit() @ 0x7fc3c37f3b26 process::DispatchEvent::visit() @ 0x7fc3c2244a08 process::ProcessBase::serve() @ 0x7fc3c37e6f50 process::ProcessManager::resume() @ 0x7fc3c37e3a78 _ZZN7process14ProcessManager12init_threadsEvENKUt_clEv @ 0x7fc3c37f3148 _ZNSt12_Bind_simpleIFZN7process14ProcessManager12init_threadsEvEUt_vEE9_M_invokeIJEEEvSt12_Index_tupleIJXspT_EEE @ 0x7fc3c37f309e _ZNSt12_Bind_simpleIFZN7process14ProcessManager12init_threadsEvEUt_vEEclEv @ 0x7fc3c37f302e _ZNSt6thread5_ImplISt12_Bind_simpleIFZN7process14ProcessManager12init_threadsEvEUt_vEEE6_M_runEv @ 0x7fc3bdc97c80 (unknown) @ 0x7fc3bd7b36ba start_thread @ 0x7fc3bd4e982d (unknown) Note that this does not crash hard so the agent stays running. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-4577) libprocess can not run on 16-byte aligned stack mandatory architecture(aarch64)
[
https://issues.apache.org/jira/browse/MESOS-4577?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15802565#comment-15802565
]
Aaron Wood commented on MESOS-4577:
---
Sure, this is to fix compilation https://reviews.apache.org/r/54993/ and this
is to fix the actual crash you get when using the linux_launcher
https://reviews.apache.org/r/54996/
> libprocess can not run on 16-byte aligned stack mandatory
> architecture(aarch64)
>
>
> Key: MESOS-4577
> URL: https://issues.apache.org/jira/browse/MESOS-4577
> Project: Mesos
> Issue Type: Bug
> Components: libprocess, stout
> Environment: Linux 10-175-112-202 4.1.6-rc3.aarch64 #1 SMP Mon Oct 12
> 01:43:03 UTC 2015 aarch64 aarch64 aarch64 GNU/Linux
>Reporter: AndyPang
>Assignee: AndyPang
> Labels: mesosphere
>
> mesos run in AArch64 will get error, the log is:
> {code}
> E0101 00:06:56.636520 32411 slave.cpp:3342] Container
> 'b6be429a-08f0-4d52-b01d-abfcb6e0106b' for executor
> 'hello.84d205ae-f626-11de-bd66-7a3f6cf980b9' of framework
> '868b9f04-9179-427b-b050-ee8f89ffa3bd-' failed to start: Failed to fork
> executor: Failed to clone child process: Failed to clone: Invalid argument
> {code}
> the "clone" achieve in libprocess 3rdparty stout library(in linux.hpp)
> packaging a syscall "clone" :
> {code:title=clone|borderStyle=solid}
> inline pid_t clone(const lambda::function& func, int flags)
> {
> // Stack for the child.
> // - unsigned long long used for best alignment.
> // - 8 MiB appears to be the default for "ulimit -s" on OSX and Linux.
> //
> // NOTE: We need to allocate the stack dynamically. This is because
> // glibc's 'clone' will modify the stack passed to it, therefore the
> // stack must NOT be shared as multiple 'clone's can be invoked
> // simultaneously.
> int stackSize = 8 * 1024 * 1024;
> unsigned long long *stack =
> new unsigned long long[stackSize/sizeof(unsigned long long)];
> pid_t pid = ::clone(
> childMain,
> [stackSize/sizeof(stack[0]) - 1], // stack grows down.
> flags,
> (void*) );
> // If CLONE_VM is not set, ::clone would create a process which runs in a
> // separate copy of the memory space of the calling process. So we destroy
> the
> // stack here to avoid memory leak. If CLONE_VM is set, ::clone would
> create a
> // thread which runs in the same memory space with the calling process.
> if (!(flags & CLONE_VM)) {
> delete[] stack;
> }
> return pid;
> }
> {code}
> syscal "clone" parameter stack is 8-byte aligned,so if in 16-byte aligned
> stack mandatory architecture(aarch64) it will get error.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MESOS-6835) Fix SIGBUS crash on ARM64/AArch64
[ https://issues.apache.org/jira/browse/MESOS-6835?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aaron Wood updated MESOS-6835: -- Description: Currently in the Linux launcher when the stack is allocated and prepared for a call to clone() it is not properly aligned. This is not an issue for x86 or x64 but for ARM64/AArch64 it is because of the requirement of having the stack aligned to a 16 byte boundary. While x86 and x64 also expect the stack to have a 16 byte aligned stack, it is not enforced. An explanation of the stack and requirements for ARM64 can be found here http://infocenter.arm.com/help/topic/com.arm.doc.ihi0055b/IHI0055B_aapcs64.pdf (specifically section 5.2.2.1 that says SP mod 16 = 0. The stack must be quad-word aligned.) Additionally, the way that the stack is currently allocated and passed to clone() accidentally chops off one entry, making a stack overflow using those missing 8 bytes a possibility. Fixing this while aligning the memory will fix both the issue of the stack overflow issue as well as the SIGBUS crash. We should also net better performance from having the stack aligned. https://reviews.apache.org/r/54996/ was: Currently in the Linux launcher when the stack is allocated and prepared for a call to clone() it is not properly aligned. This is not an issue for x86 or x64 but for ARM64/AArch64 it is because of the requirement of having the stack aligned to a 16 byte boundary. While x86 and x64 also expect the stack to have a 16 byte aligned stack, it is not enforced. An explanation of the stack and requirements for ARM64 can be found here http://infocenter.arm.com/help/topic/com.arm.doc.ihi0055b/IHI0055B_aapcs64.pdf (specifically section 5.2.2.1 that says SP mod 16 = 0. The stack must be quad-word aligned.) Additionally, the way that the stack is currently allocated and passed to clone() accidentally chops off one entry, making a stack overflow using those missing 8 bytes a possibility. Fixing this while aligning the memory will fix both the issue of the stack overflow issue as well as the SIGBUS crash. https://reviews.apache.org/r/54996/ > Fix SIGBUS crash on ARM64/AArch64 > - > > Key: MESOS-6835 > URL: https://issues.apache.org/jira/browse/MESOS-6835 > Project: Mesos > Issue Type: Bug > Components: agent, security, stout >Reporter: Aaron Wood >Assignee: Aaron Wood > > Currently in the Linux launcher when the stack is allocated and prepared for > a call to clone() it is not properly aligned. This is not an issue for x86 or > x64 but for ARM64/AArch64 it is because of the requirement of having the > stack aligned to a 16 byte boundary. While x86 and x64 also expect the stack > to have a 16 byte aligned stack, it is not enforced. An explanation of the > stack and requirements for ARM64 can be found here > http://infocenter.arm.com/help/topic/com.arm.doc.ihi0055b/IHI0055B_aapcs64.pdf > (specifically section 5.2.2.1 that says SP mod 16 = 0. The stack must be > quad-word aligned.) > Additionally, the way that the stack is currently allocated and passed to > clone() accidentally chops off one entry, making a stack overflow using those > missing 8 bytes a possibility. Fixing this while aligning the memory will fix > both the issue of the stack overflow issue as well as the SIGBUS crash. We > should also net better performance from having the stack aligned. > https://reviews.apache.org/r/54996/ -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-6835) Fix SIGBUS crash on ARM64/AArch64
[ https://issues.apache.org/jira/browse/MESOS-6835?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aaron Wood updated MESOS-6835: -- Summary: Fix SIGBUS crash on ARM64/AArch64 (was: Fix SIGBUS on ARM64/AArch64) > Fix SIGBUS crash on ARM64/AArch64 > - > > Key: MESOS-6835 > URL: https://issues.apache.org/jira/browse/MESOS-6835 > Project: Mesos > Issue Type: Bug > Components: agent, security, stout >Reporter: Aaron Wood >Assignee: Aaron Wood > > Currently in the Linux launcher when the stack is allocated and prepared for > a call to clone() it is not properly aligned. This is not an issue for x86 or > x64 but for ARM64/AArch64 it is because of the requirement of having the > stack aligned to a 16 byte boundary. While x86 and x64 also expect the stack > to have a 16 byte aligned stack, it is not enforced. An explanation of the > stack and requirements for ARM64 can be found here > http://infocenter.arm.com/help/topic/com.arm.doc.ihi0055b/IHI0055B_aapcs64.pdf > (specifically section 5.2.2.1 that says SP mod 16 = 0. The stack must be > quad-word aligned.) > Additionally, the way that the stack is currently allocated and passed to > clone() accidentally chops off one entry, making a stack overflow using those > missing 8 bytes a possibility. Fixing this while aligning the memory will fix > both the issue of the stack overflow issue as well as the SIGBUS crash. > https://reviews.apache.org/r/54996/ -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-6853) Build with CFI/CFG on platforms it's supported
[ https://issues.apache.org/jira/browse/MESOS-6853?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15799691#comment-15799691 ] Aaron Wood commented on MESOS-6853: --- Please let me know if there's any way I can help with implementing this! > Build with CFI/CFG on platforms it's supported > -- > > Key: MESOS-6853 > URL: https://issues.apache.org/jira/browse/MESOS-6853 > Project: Mesos > Issue Type: Bug > Components: cmake >Reporter: Alex Clemmer >Assignee: Alex Clemmer > > Some compiles (notably clang, MSVC) support additional security by building > with Control Flow Guards. See [1]. It is worth considering building > mesos/libmesos binaries against this API. > [1] > https://blog.trailofbits.com/2016/12/27/lets-talk-about-cfi-microsoft-edition/ -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-6835) Fix SIGBUS on ARM64/AArch64
[ https://issues.apache.org/jira/browse/MESOS-6835?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15796723#comment-15796723 ] Aaron Wood commented on MESOS-6835: --- Thanks [~AndyPang]! Just added some comments to it :) > Fix SIGBUS on ARM64/AArch64 > --- > > Key: MESOS-6835 > URL: https://issues.apache.org/jira/browse/MESOS-6835 > Project: Mesos > Issue Type: Bug > Components: agent, security, stout >Reporter: Aaron Wood >Assignee: Aaron Wood > > Currently in the Linux launcher when the stack is allocated and prepared for > a call to clone() it is not properly aligned. This is not an issue for x86 or > x64 but for ARM64/AArch64 it is because of the requirement of having the > stack aligned to a 16 byte boundary. While x86 and x64 also expect the stack > to have a 16 byte aligned stack, it is not enforced. An explanation of the > stack and requirements for ARM64 can be found here > http://infocenter.arm.com/help/topic/com.arm.doc.ihi0055b/IHI0055B_aapcs64.pdf > (specifically section 5.2.2.1 that says SP mod 16 = 0. The stack must be > quad-word aligned.) > Additionally, the way that the stack is currently allocated and passed to > clone() accidentally chops off one entry, making a stack overflow using those > missing 8 bytes a possibility. Fixing this while aligning the memory will fix > both the issue of the stack overflow issue as well as the SIGBUS crash. > https://reviews.apache.org/r/54996/ -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-4577) libprocess can not run on 16-byte aligned stack mandatory architecture(aarch64)
[
https://issues.apache.org/jira/browse/MESOS-4577?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15796719#comment-15796719
]
Aaron Wood commented on MESOS-4577:
---
[~vinodkone] Might be able to close this issue out if my patch gets accepted.
It looks like the RR associated with this was closed due to inactivity
https://reviews.apache.org/r/43182/
> libprocess can not run on 16-byte aligned stack mandatory
> architecture(aarch64)
>
>
> Key: MESOS-4577
> URL: https://issues.apache.org/jira/browse/MESOS-4577
> Project: Mesos
> Issue Type: Bug
> Components: libprocess, stout
> Environment: Linux 10-175-112-202 4.1.6-rc3.aarch64 #1 SMP Mon Oct 12
> 01:43:03 UTC 2015 aarch64 aarch64 aarch64 GNU/Linux
>Reporter: AndyPang
>Assignee: AndyPang
> Labels: mesosphere
>
> mesos run in AArch64 will get error, the log is:
> {code}
> E0101 00:06:56.636520 32411 slave.cpp:3342] Container
> 'b6be429a-08f0-4d52-b01d-abfcb6e0106b' for executor
> 'hello.84d205ae-f626-11de-bd66-7a3f6cf980b9' of framework
> '868b9f04-9179-427b-b050-ee8f89ffa3bd-' failed to start: Failed to fork
> executor: Failed to clone child process: Failed to clone: Invalid argument
> {code}
> the "clone" achieve in libprocess 3rdparty stout library(in linux.hpp)
> packaging a syscall "clone" :
> {code:title=clone|borderStyle=solid}
> inline pid_t clone(const lambda::function& func, int flags)
> {
> // Stack for the child.
> // - unsigned long long used for best alignment.
> // - 8 MiB appears to be the default for "ulimit -s" on OSX and Linux.
> //
> // NOTE: We need to allocate the stack dynamically. This is because
> // glibc's 'clone' will modify the stack passed to it, therefore the
> // stack must NOT be shared as multiple 'clone's can be invoked
> // simultaneously.
> int stackSize = 8 * 1024 * 1024;
> unsigned long long *stack =
> new unsigned long long[stackSize/sizeof(unsigned long long)];
> pid_t pid = ::clone(
> childMain,
> [stackSize/sizeof(stack[0]) - 1], // stack grows down.
> flags,
> (void*) );
> // If CLONE_VM is not set, ::clone would create a process which runs in a
> // separate copy of the memory space of the calling process. So we destroy
> the
> // stack here to avoid memory leak. If CLONE_VM is set, ::clone would
> create a
> // thread which runs in the same memory space with the calling process.
> if (!(flags & CLONE_VM)) {
> delete[] stack;
> }
> return pid;
> }
> {code}
> syscal "clone" parameter stack is 8-byte aligned,so if in 16-byte aligned
> stack mandatory architecture(aarch64) it will get error.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MESOS-6835) Fix SIGBUS on ARM64/AArch64
[ https://issues.apache.org/jira/browse/MESOS-6835?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aaron Wood updated MESOS-6835: -- Component/s: agent > Fix SIGBUS on ARM64/AArch64 > --- > > Key: MESOS-6835 > URL: https://issues.apache.org/jira/browse/MESOS-6835 > Project: Mesos > Issue Type: Bug > Components: agent, security, stout >Reporter: Aaron Wood >Assignee: Aaron Wood > > Currently in the Linux launcher when the stack is allocated and prepared for > a call to clone() it is not properly aligned. This is not an issue for x86 or > x64 but for ARM64/AArch64 it is because of the requirement of having the > stack aligned to a 16 byte boundary. While x86 and x64 also expect the stack > to have a 16 byte aligned stack, it is not enforced. An explanation of the > stack and requirements for ARM64 can be found here > http://infocenter.arm.com/help/topic/com.arm.doc.ihi0055b/IHI0055B_aapcs64.pdf > (specifically section 5.2.2.1 that says SP mod 16 = 0. The stack must be > quad-word aligned.) > Additionally, the way that the stack is currently allocated and passed to > clone() accidentally chops off one entry, making a stack overflow using those > missing 8 bytes a possibility. Fixing this while aligning the memory will fix > both the issue of the stack overflow issue as well as the SIGBUS crash. > https://reviews.apache.org/r/54996/ -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-4577) libprocess can not run on 16-byte aligned stack mandatory architecture(aarch64)
[
https://issues.apache.org/jira/browse/MESOS-4577?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15795492#comment-15795492
]
Aaron Wood commented on MESOS-4577:
---
I don't believe the requirement has changed in the recent kernels. We're
running 4.9 and still see a SIGBUG when using the misaligned stack on aarch64.
From that kernel patch it sounds like they've just changed the behavior for
what happens when you use an unaligned stack.
> libprocess can not run on 16-byte aligned stack mandatory
> architecture(aarch64)
>
>
> Key: MESOS-4577
> URL: https://issues.apache.org/jira/browse/MESOS-4577
> Project: Mesos
> Issue Type: Bug
> Components: libprocess, stout
> Environment: Linux 10-175-112-202 4.1.6-rc3.aarch64 #1 SMP Mon Oct 12
> 01:43:03 UTC 2015 aarch64 aarch64 aarch64 GNU/Linux
>Reporter: AndyPang
>Assignee: AndyPang
> Labels: mesosphere
>
> mesos run in AArch64 will get error, the log is:
> {code}
> E0101 00:06:56.636520 32411 slave.cpp:3342] Container
> 'b6be429a-08f0-4d52-b01d-abfcb6e0106b' for executor
> 'hello.84d205ae-f626-11de-bd66-7a3f6cf980b9' of framework
> '868b9f04-9179-427b-b050-ee8f89ffa3bd-' failed to start: Failed to fork
> executor: Failed to clone child process: Failed to clone: Invalid argument
> {code}
> the "clone" achieve in libprocess 3rdparty stout library(in linux.hpp)
> packaging a syscall "clone" :
> {code:title=clone|borderStyle=solid}
> inline pid_t clone(const lambda::function& func, int flags)
> {
> // Stack for the child.
> // - unsigned long long used for best alignment.
> // - 8 MiB appears to be the default for "ulimit -s" on OSX and Linux.
> //
> // NOTE: We need to allocate the stack dynamically. This is because
> // glibc's 'clone' will modify the stack passed to it, therefore the
> // stack must NOT be shared as multiple 'clone's can be invoked
> // simultaneously.
> int stackSize = 8 * 1024 * 1024;
> unsigned long long *stack =
> new unsigned long long[stackSize/sizeof(unsigned long long)];
> pid_t pid = ::clone(
> childMain,
> [stackSize/sizeof(stack[0]) - 1], // stack grows down.
> flags,
> (void*) );
> // If CLONE_VM is not set, ::clone would create a process which runs in a
> // separate copy of the memory space of the calling process. So we destroy
> the
> // stack here to avoid memory leak. If CLONE_VM is set, ::clone would
> create a
> // thread which runs in the same memory space with the calling process.
> if (!(flags & CLONE_VM)) {
> delete[] stack;
> }
> return pid;
> }
> {code}
> syscal "clone" parameter stack is 8-byte aligned,so if in 16-byte aligned
> stack mandatory architecture(aarch64) it will get error.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MESOS-6835) Fix SIGBUS on ARM64/AArch64
[ https://issues.apache.org/jira/browse/MESOS-6835?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aaron Wood updated MESOS-6835: -- Description: Currently in the Linux launcher when the stack is allocated and prepared for a call to clone() it is not properly aligned. This is not an issue for x86 or x64 but for ARM64/AArch64 it is because of the requirement of having the stack aligned to a 16 byte boundary. While x86 and x64 also expect the stack to have a 16 byte aligned stack, it is not enforced. An explanation of the stack and requirements for ARM64 can be found here http://infocenter.arm.com/help/topic/com.arm.doc.ihi0055b/IHI0055B_aapcs64.pdf (specifically section 5.2.2.1 that says SP mod 16 = 0. The stack must be quad-word aligned.) Additionally, the way that the stack is currently allocated and passed to clone() accidentally chops off one entry, making a stack overflow using those missing 8 bytes a possibility. Fixing this while aligning the memory will fix both the issue of the stack overflow issue as well as the SIGBUS crash. https://reviews.apache.org/r/54996/ was: Currently in the Linux launcher when the stack is allocated and prepared for a call to clone() it is not properly aligned. This is not an issue for x86 or x64 but for ARM64/AArch64 it is because of the requirement of having the stack aligned to a 16 byte boundary. While x86 and x64 also expect the stack to have a 16 byte aligned stack, it is not enforced. Additionally, the way that the stack is currently allocated and passed to clone() accidentally chops off one entry, making a stack overflow using those missing 8 bytes a possibility. Fixing this while aligning the memory will fix both the issue of the stack overflow issue as well as the SIGBUS crash. https://reviews.apache.org/r/54996/ > Fix SIGBUS on ARM64/AArch64 > --- > > Key: MESOS-6835 > URL: https://issues.apache.org/jira/browse/MESOS-6835 > Project: Mesos > Issue Type: Bug > Components: security, stout >Reporter: Aaron Wood >Assignee: Aaron Wood > > Currently in the Linux launcher when the stack is allocated and prepared for > a call to clone() it is not properly aligned. This is not an issue for x86 or > x64 but for ARM64/AArch64 it is because of the requirement of having the > stack aligned to a 16 byte boundary. While x86 and x64 also expect the stack > to have a 16 byte aligned stack, it is not enforced. An explanation of the > stack and requirements for ARM64 can be found here > http://infocenter.arm.com/help/topic/com.arm.doc.ihi0055b/IHI0055B_aapcs64.pdf > (specifically section 5.2.2.1 that says SP mod 16 = 0. The stack must be > quad-word aligned.) > Additionally, the way that the stack is currently allocated and passed to > clone() accidentally chops off one entry, making a stack overflow using those > missing 8 bytes a possibility. Fixing this while aligning the memory will fix > both the issue of the stack overflow issue as well as the SIGBUS crash. > https://reviews.apache.org/r/54996/ -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-6834) Allow Mesos to compile on ARM64/AArch64
[ https://issues.apache.org/jira/browse/MESOS-6834?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aaron Wood updated MESOS-6834: -- Description: Mesos will not compile on ARM64/AArch64 without a patch to the version of LevelDB that is used within Mesos. While the fix is already in newer versions of LevelDB it's not something that Mesos pulls down. The main issue is that the AtomicPointer header needs to be aware of other architectures to provide its functionality to those architectures. https://reviews.apache.org/r/54993/ was: Mesos will not compile on ARM64/AArch64 without a patch to the version of LevelDB that is used within Mesos. While the fix is already in newer versions of LevelDB it's not something that Mesos pulls down. The main issue is that the AtomicPointer header needs to be aware of other architectures to provide its functionality to those architectures. > Allow Mesos to compile on ARM64/AArch64 > --- > > Key: MESOS-6834 > URL: https://issues.apache.org/jira/browse/MESOS-6834 > Project: Mesos > Issue Type: Bug > Components: build, general >Reporter: Aaron Wood >Assignee: Aaron Wood > > Mesos will not compile on ARM64/AArch64 without a patch to the version of > LevelDB that is used within Mesos. While the fix is already in newer versions > of LevelDB it's not something that Mesos pulls down. > The main issue is that the AtomicPointer header needs to be aware of other > architectures to provide its functionality to those architectures. > https://reviews.apache.org/r/54993/ -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-6835) Fix SIGBUS on ARM64/AArch64
[ https://issues.apache.org/jira/browse/MESOS-6835?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aaron Wood updated MESOS-6835: -- Description: Currently in the Linux launcher when the stack is allocated and prepared for a call to clone() it is not properly aligned. This is not an issue for x86 or x64 but for ARM64/AArch64 it is because of the requirement of having the stack aligned to a 16 byte boundary. While x86 and x64 also expect the stack to have a 16 byte aligned stack, it is not enforced. Additionally, the way that the stack is currently allocated and passed to clone() accidentally chops off one entry, making a stack overflow using those missing 8 bytes a possibility. Fixing this while aligning the memory will fix both the issue of the stack overflow issue as well as the SIGBUS crash. https://reviews.apache.org/r/54996/ was: Currently in the Linux launcher when the stack is allocated and prepared for a call to clone() it is not properly aligned. This is not an issue for x86 or x64 but for ARM64/AArch64 it is because of the requirement of having the stack aligned to a 16 byte boundary. While x86 and x64 also expect the stack to have a 16 byte aligned stack, it is not enforced. Additionally, the way that the stack is currently allocated and passed to clone() accidentally chops off one entry, making a stack overflow using those missing 8 bytes a possibility. Fixing this while aligning the memory will fix both the issue of the stack overflow issue as well as the SIGBUS crash. > Fix SIGBUS on ARM64/AArch64 > --- > > Key: MESOS-6835 > URL: https://issues.apache.org/jira/browse/MESOS-6835 > Project: Mesos > Issue Type: Bug > Components: security, stout >Reporter: Aaron Wood >Assignee: Aaron Wood > > Currently in the Linux launcher when the stack is allocated and prepared for > a call to clone() it is not properly aligned. This is not an issue for x86 or > x64 but for ARM64/AArch64 it is because of the requirement of having the > stack aligned to a 16 byte boundary. While x86 and x64 also expect the stack > to have a 16 byte aligned stack, it is not enforced. > Additionally, the way that the stack is currently allocated and passed to > clone() accidentally chops off one entry, making a stack overflow using those > missing 8 bytes a possibility. Fixing this while aligning the memory will fix > both the issue of the stack overflow issue as well as the SIGBUS crash. > https://reviews.apache.org/r/54996/ -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-6834) Allow Mesos to compile on ARM64/AArch64
[ https://issues.apache.org/jira/browse/MESOS-6834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15770931#comment-15770931 ] Aaron Wood commented on MESOS-6834: --- [~neilc] here it is https://reviews.apache.org/r/51053/ > Allow Mesos to compile on ARM64/AArch64 > --- > > Key: MESOS-6834 > URL: https://issues.apache.org/jira/browse/MESOS-6834 > Project: Mesos > Issue Type: Bug > Components: build, general >Reporter: Aaron Wood >Assignee: Aaron Wood > > Mesos will not compile on ARM64/AArch64 without a patch to the version of > LevelDB that is used within Mesos. While the fix is already in newer versions > of LevelDB it's not something that Mesos pulls down. > The main issue is that the AtomicPointer header needs to be aware of other > architectures to provide its functionality to those architectures. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-6834) Allow Mesos to compile on ARM64/AArch64
[ https://issues.apache.org/jira/browse/MESOS-6834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15770900#comment-15770900 ] Aaron Wood commented on MESOS-6834: --- I had asked a few people about upgrading LevelDB a while back and I think they pointed me to an RR that was already open for this. It looked like some benchmarking was being done but that it was a very low priority for the project. FWIW this is the patch I made to get this to work without upgrading LevelDB. https://github.com/verizonlabs/mesos/commit/7ef493d51de5853e0c82471af36603f87146aec2 If LevelDB can be upgraded I can get rid of that :) > Allow Mesos to compile on ARM64/AArch64 > --- > > Key: MESOS-6834 > URL: https://issues.apache.org/jira/browse/MESOS-6834 > Project: Mesos > Issue Type: Bug > Components: build, general >Reporter: Aaron Wood >Assignee: Aaron Wood > > Mesos will not compile on ARM64/AArch64 without a patch to the version of > LevelDB that is used within Mesos. While the fix is already in newer versions > of LevelDB it's not something that Mesos pulls down. > The main issue is that the AtomicPointer header needs to be aware of other > architectures to provide its functionality to those architectures. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MESOS-6835) Fix SIGBUS on ARM64/AArch64
Aaron Wood created MESOS-6835: - Summary: Fix SIGBUS on ARM64/AArch64 Key: MESOS-6835 URL: https://issues.apache.org/jira/browse/MESOS-6835 Project: Mesos Issue Type: Bug Components: security, stout Reporter: Aaron Wood Assignee: Aaron Wood Currently in the Linux launcher when the stack is allocated and prepared for a call to clone() it is not properly aligned. This is not an issue for x86 or x64 but for ARM64/AArch64 it is because of the requirement of having the stack aligned to a 16 byte boundary. While x86 and x64 also expect the stack to have a 16 byte aligned stack, it is not enforced. Additionally, the way that the stack is currently allocated and passed to clone() accidentally chops off one entry, making a stack overflow using those missing 8 bytes a possibility. Fixing this while aligning the memory will fix both the issue of the stack overflow issue as well as the SIGBUS crash. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MESOS-6834) Allow Mesos to compile on ARM64/AArch64
Aaron Wood created MESOS-6834: - Summary: Allow Mesos to compile on ARM64/AArch64 Key: MESOS-6834 URL: https://issues.apache.org/jira/browse/MESOS-6834 Project: Mesos Issue Type: Bug Components: build, general Reporter: Aaron Wood Assignee: Aaron Wood Mesos will not compile on ARM64/AArch64 without a patch to the version of LevelDB that is used within Mesos. While the fix is already in newer versions of LevelDB it's not something that Mesos pulls down. The main issue is that the AtomicPointer header needs to be aware of other architectures to provide its functionality to those architectures. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-6830) Mesos fails to link with gold when providing -pie without -fPIC
[ https://issues.apache.org/jira/browse/MESOS-6830?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aaron Wood updated MESOS-6830: -- Description: Gold linker complains about using -pie without -fPIC: /usr/bin/ld: local/mesos_local-main.o: relocation R_X86_64_32 against `.rodata' can not be used when making a shared object; recompile with -fPIC local/mesos_local-main.o: error adding symbols: Bad value collect2: error: ld returned 1 exit status /usr/bin/ld: cli/mesos-mesos.o: relocation R_X86_64_32 against `.rodata' can not be used when making a shared object; recompile with -fPIC cli/mesos-mesos.o: error adding symbols: Bad value collect2: error: ld returned 1 exit status Makefile:5208: recipe for target 'mesos-local' failed make[2]: *** [mesos-local] Error 1 make[2]: *** Waiting for unfinished jobs /Makefile:5131: recipe for target 'mesos' failed make[2]: *** [mesos] Error 1 usr/bin/ld: log/mesos_log-main.o: relocation R_X86_64_32 against `.bss' can not be used when making a shared object; recompile with -fPIC log/mesos_log-main.o: error adding symbols: Bad value collect2: error: ld returned 1 exit status https://reviews.apache.org/r/54953/ was: Gold linker complains about using -pie without -fPIC: /usr/bin/ld: local/mesos_local-main.o: relocation R_X86_64_32 against `.rodata' can not be used when making a shared object; recompile with -fPIC local/mesos_local-main.o: error adding symbols: Bad value collect2: error: ld returned 1 exit status /usr/bin/ld: cli/mesos-mesos.o: relocation R_X86_64_32 against `.rodata' can not be used when making a shared object; recompile with -fPIC cli/mesos-mesos.o: error adding symbols: Bad value collect2: error: ld returned 1 exit status Makefile:5208: recipe for target 'mesos-local' failed make[2]: *** [mesos-local] Error 1 make[2]: *** Waiting for unfinished jobs /Makefile:5131: recipe for target 'mesos' failed make[2]: *** [mesos] Error 1 usr/bin/ld: log/mesos_log-main.o: relocation R_X86_64_32 against `.bss' can not be used when making a shared object; recompile with -fPIC log/mesos_log-main.o: error adding symbols: Bad value collect2: error: ld returned 1 exit status > Mesos fails to link with gold when providing -pie without -fPIC > --- > > Key: MESOS-6830 > URL: https://issues.apache.org/jira/browse/MESOS-6830 > Project: Mesos > Issue Type: Bug > Components: build, libprocess, security, stout >Reporter: Aaron Wood >Assignee: Aaron Wood > > Gold linker complains about using -pie without -fPIC: > /usr/bin/ld: local/mesos_local-main.o: relocation R_X86_64_32 against > `.rodata' can not be used when making a shared object; recompile with -fPIC > local/mesos_local-main.o: error adding symbols: Bad value > collect2: error: ld returned 1 exit status > /usr/bin/ld: cli/mesos-mesos.o: relocation R_X86_64_32 against `.rodata' can > not be used when making a shared object; recompile with -fPIC > cli/mesos-mesos.o: error adding symbols: Bad value > collect2: error: ld returned 1 exit status > Makefile:5208: recipe for target 'mesos-local' failed > make[2]: *** [mesos-local] Error 1 > make[2]: *** Waiting for unfinished jobs > /Makefile:5131: recipe for target 'mesos' failed > make[2]: *** [mesos] Error 1 > usr/bin/ld: log/mesos_log-main.o: relocation R_X86_64_32 against `.bss' can > not be used when making a shared object; recompile with -fPIC > log/mesos_log-main.o: error adding symbols: Bad value > collect2: error: ld returned 1 exit status > https://reviews.apache.org/r/54953/ -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-6829) Mesos fails to compile when using FORTIFY_SOURCE without optimizations
[ https://issues.apache.org/jira/browse/MESOS-6829?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aaron Wood updated MESOS-6829: -- Description: Fome some versions of gcc/glibc a warning will be produced with FORTIFY_SOURCE is used without optimizations enabled (see here for related information https://sourceware.org/bugzilla/show_bug.cgi?id=13979). This only happens in some environments such as CentOS 7 and Arch Linux with GCC 6.2. Probably one of the reasons why it didn't get caught earlier by CI: "This #warning appears to be causing more grief than it is solving; for example, see this autoconf thread that complains that it is breaking configure scripts, and therefore Debian's decision to revert this patch in their build of glibc: https://lists.gnu.org/archive/html/autoconf/2013-05/msg3.html http://anonscm.debian.org/viewvc/pkg-glibc/glibc-package/trunk/debian/patches/any/local-revert-bz13979.diff?revision=5553=markup; https://reviews.apache.org/r/54949/ https://reviews.apache.org/r/54950/ https://reviews.apache.org/r/54951/ was: Fome some versions of gcc/glibc a warning will be produced with FORTIFY_SOURCE is used without optimizations enabled (see here for related information https://sourceware.org/bugzilla/show_bug.cgi?id=13979). This only happens in some environments such as CentOS 7 and Arch Linux with GCC 6.2. Probably one of the reasons why it didn't get caught earlier by CI: "This #warning appears to be causing more grief than it is solving; for example, see this autoconf thread that complains that it is breaking configure scripts, and therefore Debian's decision to revert this patch in their build of glibc: https://lists.gnu.org/archive/html/autoconf/2013-05/msg3.html http://anonscm.debian.org/viewvc/pkg-glibc/glibc-package/trunk/debian/patches/any/local-revert-bz13979.diff?revision=5553=markup; > Mesos fails to compile when using FORTIFY_SOURCE without optimizations > -- > > Key: MESOS-6829 > URL: https://issues.apache.org/jira/browse/MESOS-6829 > Project: Mesos > Issue Type: Bug > Components: build, libprocess, security, stout >Reporter: Aaron Wood >Assignee: Aaron Wood > > Fome some versions of gcc/glibc a warning will be produced with > FORTIFY_SOURCE is used without optimizations enabled (see here for related > information https://sourceware.org/bugzilla/show_bug.cgi?id=13979). This only > happens in some environments such as CentOS 7 and Arch Linux with GCC 6.2. > Probably one of the reasons why it didn't get caught earlier by CI: > "This #warning appears to be causing more grief than it is solving; for > example, see this autoconf thread that complains that it is breaking > configure scripts, and therefore Debian's decision to revert this patch in > their build of glibc: > https://lists.gnu.org/archive/html/autoconf/2013-05/msg3.html > http://anonscm.debian.org/viewvc/pkg-glibc/glibc-package/trunk/debian/patches/any/local-revert-bz13979.diff?revision=5553=markup; > https://reviews.apache.org/r/54949/ > https://reviews.apache.org/r/54950/ > https://reviews.apache.org/r/54951/ -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-6830) Mesos fails to link with gold when providing -pie without -fPIC
[ https://issues.apache.org/jira/browse/MESOS-6830?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aaron Wood updated MESOS-6830: -- Description: Gold linker complains about using -pie without -fPIC: /usr/bin/ld: local/mesos_local-main.o: relocation R_X86_64_32 against `.rodata' can not be used when making a shared object; recompile with -fPIC local/mesos_local-main.o: error adding symbols: Bad value collect2: error: ld returned 1 exit status /usr/bin/ld: cli/mesos-mesos.o: relocation R_X86_64_32 against `.rodata' can not be used when making a shared object; recompile with -fPIC cli/mesos-mesos.o: error adding symbols: Bad value collect2: error: ld returned 1 exit status Makefile:5208: recipe for target 'mesos-local' failed make[2]: *** [mesos-local] Error 1 make[2]: *** Waiting for unfinished jobs /Makefile:5131: recipe for target 'mesos' failed make[2]: *** [mesos] Error 1 usr/bin/ld: log/mesos_log-main.o: relocation R_X86_64_32 against `.bss' can not be used when making a shared object; recompile with -fPIC log/mesos_log-main.o: error adding symbols: Bad value collect2: error: ld returned 1 exit status was: Gold linker complains about using -pie without -fPIC: /bin/bash ../libtool --tag=CXX --mode=link g++ -pthread -Wall -Wsign-compare -Wformat-security -g1 -O0 -Wno-unused-local-typedefs -std=c++11 -pie -Wl,--as-needed -o mesos-log log/mesos_log-main.o libmesos.la -lz -lsvn_delta-1 -lsvn_subr-1 -lsasl2 -lcurl -lapr-1 -lz -lrt /bin/bash ../libtool --tag=CXX --mode=link g++ -pthread -Wall -Wsign-compare -Wformat-security -g1 -O0 -Wno-unused-local-typedefs -std=c++11 -pie -Wl,--as-needed -o mesos-local local/mesos_local-main.o libmesos.la -lz -lsvn_delta-1 -lsvn_subr-1 -lsasl2 -lcurl -lapr-1 -lz -lrt /bin/bash ../libtool --tag=CXX --mode=link g++ -pthread -Wall -Wsign-compare -Wformat-security -g1 -O0 -Wno-unused-local-typedefs -std=c++11 -pie -Wl,--as-needed -o mesos cli/mesos-mesos.o libmesos.la -lz -lsvn_delta-1 -lsvn_subr-1 -lsasl2 -lcurl -lapr-1 -lz -lrt libtool: link: g++ -pthread -Wall -Wsign-compare -Wformat-security -g1 -O0 -Wno-unused-local-typedefs -std=c++11 -pie -Wl,--as-needed -o .libs/mesos-local local/mesos_local-main.o ./.libs/libmesos.so /usr/lib/x86_64-linux-gnu/libsvn_delta-1.so /usr/lib/x86_64-linux-gnu/libsvn_subr-1.so -lsasl2 /usr/lib/x86_64-linux-gnu/libcurl-nss.so /usr/lib/x86_64-linux-gnu/libapr-1.so -lz -lrt -pthread libtool: link: g++ -pthread -Wall -Wsign-compare -Wformat-security -g1 -O0 -Wno-unused-local-typedefs -std=c++11 -pie -Wl,--as-needed -o .libs/mesos-log log/mesos_log-main.o ./.libs/libmesos.so /usr/lib/x86_64-linux-gnu/libsvn_delta-1.so /usr/lib/x86_64-linux-gnu/libsvn_subr-1.so -lsasl2 /usr/lib/x86_64-linux-gnu/libcurl-nss.so /usr/lib/x86_64-linux-gnu/libapr-1.so -lz -lrt -pthread libtool: link: g++ -pthread -Wall -Wsign-compare -Wformat-security -g1 -O0 -Wno-unused-local-typedefs -std=c++11 -pie -Wl,--as-needed -o .libs/mesos cli/mesos-mesos.o ./.libs/libmesos.so /usr/lib/x86_64-linux-gnu/libsvn_delta-1.so /usr/lib/x86_64-linux-gnu/libsvn_subr-1.so -lsasl2 /usr/lib/x86_64-linux-gnu/libcurl-nss.so /usr/lib/x86_64-linux-gnu/libapr-1.so -lz -lrt -pthread /usr/bin/ld: local/mesos_local-main.o: relocation R_X86_64_32 against `.rodata' can not be used when making a shared object; recompile with -fPIC local/mesos_local-main.o: error adding symbols: Bad value collect2: error: ld returned 1 exit status /usr/bin/ld: cli/mesos-mesos.o: relocation R_X86_64_32 against `.rodata' can not be used when making a shared object; recompile with -fPIC cli/mesos-mesos.o: error adding symbols: Bad value collect2: error: ld returned 1 exit status Makefile:5208: recipe for target 'mesos-local' failed make[2]: *** [mesos-local] Error 1 make[2]: *** Waiting for unfinished jobs /Makefile:5131: recipe for target 'mesos' failed make[2]: *** [mesos] Error 1 usr/bin/ld: log/mesos_log-main.o: relocation R_X86_64_32 against `.bss' can not be used when making a shared object; recompile with -fPIC log/mesos_log-main.o: error adding symbols: Bad value collect2: error: ld returned 1 exit status > Mesos fails to link with gold when providing -pie without -fPIC > --- > > Key: MESOS-6830 > URL: https://issues.apache.org/jira/browse/MESOS-6830 > Project: Mesos > Issue Type: Bug > Components: build, libprocess, security, stout >Reporter: Aaron Wood >Assignee: Aaron Wood > > Gold linker complains about using -pie without -fPIC: > /usr/bin/ld: local/mesos_local-main.o: relocation R_X86_64_32 against > `.rodata' can not be used when making a shared object; recompile with -fPIC > local/mesos_local-main.o: error adding symbols: Bad value > collect2: error: ld returned 1 exit status > /usr/bin/ld: cli/mesos-mesos.o: relocation
[jira] [Created] (MESOS-6830) Mesos fails to link with gold when providing -pie without -fPIC
Aaron Wood created MESOS-6830: - Summary: Mesos fails to link with gold when providing -pie without -fPIC Key: MESOS-6830 URL: https://issues.apache.org/jira/browse/MESOS-6830 Project: Mesos Issue Type: Bug Components: build, libprocess, security, stout Reporter: Aaron Wood Assignee: Aaron Wood Gold linker complains about using -pie without -fPIC: /bin/bash ../libtool --tag=CXX --mode=link g++ -pthread -Wall -Wsign-compare -Wformat-security -g1 -O0 -Wno-unused-local-typedefs -std=c++11 -pie -Wl,--as-needed -o mesos-log log/mesos_log-main.o libmesos.la -lz -lsvn_delta-1 -lsvn_subr-1 -lsasl2 -lcurl -lapr-1 -lz -lrt /bin/bash ../libtool --tag=CXX --mode=link g++ -pthread -Wall -Wsign-compare -Wformat-security -g1 -O0 -Wno-unused-local-typedefs -std=c++11 -pie -Wl,--as-needed -o mesos-local local/mesos_local-main.o libmesos.la -lz -lsvn_delta-1 -lsvn_subr-1 -lsasl2 -lcurl -lapr-1 -lz -lrt /bin/bash ../libtool --tag=CXX --mode=link g++ -pthread -Wall -Wsign-compare -Wformat-security -g1 -O0 -Wno-unused-local-typedefs -std=c++11 -pie -Wl,--as-needed -o mesos cli/mesos-mesos.o libmesos.la -lz -lsvn_delta-1 -lsvn_subr-1 -lsasl2 -lcurl -lapr-1 -lz -lrt libtool: link: g++ -pthread -Wall -Wsign-compare -Wformat-security -g1 -O0 -Wno-unused-local-typedefs -std=c++11 -pie -Wl,--as-needed -o .libs/mesos-local local/mesos_local-main.o ./.libs/libmesos.so /usr/lib/x86_64-linux-gnu/libsvn_delta-1.so /usr/lib/x86_64-linux-gnu/libsvn_subr-1.so -lsasl2 /usr/lib/x86_64-linux-gnu/libcurl-nss.so /usr/lib/x86_64-linux-gnu/libapr-1.so -lz -lrt -pthread libtool: link: g++ -pthread -Wall -Wsign-compare -Wformat-security -g1 -O0 -Wno-unused-local-typedefs -std=c++11 -pie -Wl,--as-needed -o .libs/mesos-log log/mesos_log-main.o ./.libs/libmesos.so /usr/lib/x86_64-linux-gnu/libsvn_delta-1.so /usr/lib/x86_64-linux-gnu/libsvn_subr-1.so -lsasl2 /usr/lib/x86_64-linux-gnu/libcurl-nss.so /usr/lib/x86_64-linux-gnu/libapr-1.so -lz -lrt -pthread libtool: link: g++ -pthread -Wall -Wsign-compare -Wformat-security -g1 -O0 -Wno-unused-local-typedefs -std=c++11 -pie -Wl,--as-needed -o .libs/mesos cli/mesos-mesos.o ./.libs/libmesos.so /usr/lib/x86_64-linux-gnu/libsvn_delta-1.so /usr/lib/x86_64-linux-gnu/libsvn_subr-1.so -lsasl2 /usr/lib/x86_64-linux-gnu/libcurl-nss.so /usr/lib/x86_64-linux-gnu/libapr-1.so -lz -lrt -pthread /usr/bin/ld: local/mesos_local-main.o: relocation R_X86_64_32 against `.rodata' can not be used when making a shared object; recompile with -fPIC local/mesos_local-main.o: error adding symbols: Bad value collect2: error: ld returned 1 exit status /usr/bin/ld: cli/mesos-mesos.o: relocation R_X86_64_32 against `.rodata' can not be used when making a shared object; recompile with -fPIC cli/mesos-mesos.o: error adding symbols: Bad value collect2: error: ld returned 1 exit status Makefile:5208: recipe for target 'mesos-local' failed make[2]: *** [mesos-local] Error 1 make[2]: *** Waiting for unfinished jobs /Makefile:5131: recipe for target 'mesos' failed make[2]: *** [mesos] Error 1 usr/bin/ld: log/mesos_log-main.o: relocation R_X86_64_32 against `.bss' can not be used when making a shared object; recompile with -fPIC log/mesos_log-main.o: error adding symbols: Bad value collect2: error: ld returned 1 exit status -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MESOS-6829) Mesos fails to compile when using FORTIFY_SOURCE without optimizations
Aaron Wood created MESOS-6829: - Summary: Mesos fails to compile when using FORTIFY_SOURCE without optimizations Key: MESOS-6829 URL: https://issues.apache.org/jira/browse/MESOS-6829 Project: Mesos Issue Type: Bug Components: build, libprocess, security, stout Reporter: Aaron Wood Assignee: Aaron Wood Fome some versions of gcc/glibc a warning will be produced with FORTIFY_SOURCE is used without optimizations enabled (see here for related information https://sourceware.org/bugzilla/show_bug.cgi?id=13979). This only happens in some environments such as CentOS 7 and Arch Linux with GCC 6.2. Probably one of the reasons why it didn't get caught earlier by CI: "This #warning appears to be causing more grief than it is solving; for example, see this autoconf thread that complains that it is breaking configure scripts, and therefore Debian's decision to revert this patch in their build of glibc: https://lists.gnu.org/archive/html/autoconf/2013-05/msg3.html http://anonscm.debian.org/viewvc/pkg-glibc/glibc-package/trunk/debian/patches/any/local-revert-bz13979.diff?revision=5553=markup; -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-2952) Provide user namespaces for privileged access inside containers
[ https://issues.apache.org/jira/browse/MESOS-2952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15627630#comment-15627630 ] Aaron Wood commented on MESOS-2952: --- This would be great to have. If there's anything I can help with please let me know! > Provide user namespaces for privileged access inside containers > --- > > Key: MESOS-2952 > URL: https://issues.apache.org/jira/browse/MESOS-2952 > Project: Mesos > Issue Type: Epic >Reporter: Paul Brett >Assignee: Vaibhav Khanduja > > User namespaces allow per-namespace mappings of user and group IDs. This > means that a process's user and group IDs inside a user namespace can be > different from its IDs outside of the namespace. Most notably, a process can > have a nonzero user ID outside a namespace while at the same time having a > user ID of zero inside the namespace; in other words, the process is > unprivileged for operations outside the user namespace but has root > privileges inside the namespace. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-6229) Default to using hardened compilation flags
[ https://issues.apache.org/jira/browse/MESOS-6229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aaron Wood updated MESOS-6229: -- Description: Provide a default set of hardened compilation flags to help protect against overflows and other attacks. Apply to libprocess and stout as well. Current set of flags that were discussed on slack to implement: -Wformat-security -Wstack-protector -fstack-protector-strong (-fstack-protector-all might be overkill, it could be more effective to use this. Requires gcc >= 4.9 which should be reasonable. Detect compiler support and use what we can but prefer -fstack-protector-strong) -pie -fPIE -fPIC -D_FORTIFY_SOURCE=2 -Wl,-z,relro,-z,now (currently not a part of the patch, this should be another JIRA) -fno-omit-frame-pointer https://reviews.apache.org/r/52645/ https://reviews.apache.org/r/52695/ https://reviews.apache.org/r/52696/ was: Provide a default set of hardened compilation flags to help protect against overflows and other attacks. Apply to libprocess and stout as well. Current set of flags that were discussed on slack to implement: -Wformat-security -Wstack-protector -fstack-protector-strong (-fstack-protector-all might be overkill, it could be more effective to use this. Requires gcc >= 4.9 which should be reasonable) -pie -fPIE -fPIC -D_FORTIFY_SOURCE=2 -Wl,-z,relro,-z,now (currently not a part of the patch) -fno-omit-frame-pointer https://reviews.apache.org/r/52645/ https://reviews.apache.org/r/52695/ https://reviews.apache.org/r/52696/ > Default to using hardened compilation flags > --- > > Key: MESOS-6229 > URL: https://issues.apache.org/jira/browse/MESOS-6229 > Project: Mesos > Issue Type: Improvement >Reporter: Aaron Wood >Assignee: Aaron Wood >Priority: Minor > Labels: c++, clang, gcc, security > > Provide a default set of hardened compilation flags to help protect against > overflows and other attacks. Apply to libprocess and stout as well. Current > set of flags that were discussed on slack to implement: > -Wformat-security > -Wstack-protector > -fstack-protector-strong (-fstack-protector-all might be overkill, it could > be more effective to use this. Requires gcc >= 4.9 which should be > reasonable. Detect compiler support and use what we can but prefer > -fstack-protector-strong) > -pie > -fPIE > -fPIC > -D_FORTIFY_SOURCE=2 > -Wl,-z,relro,-z,now (currently not a part of the patch, this should be > another JIRA) > -fno-omit-frame-pointer > https://reviews.apache.org/r/52645/ > https://reviews.apache.org/r/52695/ > https://reviews.apache.org/r/52696/ -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-6239) Fix warnings and errors produced by new hardened CXXFLAGS
[ https://issues.apache.org/jira/browse/MESOS-6239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aaron Wood updated MESOS-6239: -- Description: Most of the new warnings/errors come from libprocess/stout as there were never any CXXFLAGS propagated to them. https://reviews.apache.org/r/52647/ https://reviews.apache.org/r/52754/ https://reviews.apache.org/r/52886/ was: Most of the new warnings/errors come from libprocess/stout as there were never any CXXFLAGS propagated to them. https://reviews.apache.org/r/52647/ https://reviews.apache.org/r/52754/ > Fix warnings and errors produced by new hardened CXXFLAGS > - > > Key: MESOS-6239 > URL: https://issues.apache.org/jira/browse/MESOS-6239 > Project: Mesos > Issue Type: Improvement >Reporter: Aaron Wood >Assignee: Aaron Wood >Priority: Minor > Labels: c++, clang, gcc, libprocess, security, stout > > Most of the new warnings/errors come from libprocess/stout as there were > never any CXXFLAGS propagated to them. > https://reviews.apache.org/r/52647/ > https://reviews.apache.org/r/52754/ > https://reviews.apache.org/r/52886/ -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-6239) Fix warnings and errors produced by new hardened CXXFLAGS
[ https://issues.apache.org/jira/browse/MESOS-6239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aaron Wood updated MESOS-6239: -- Description: Most of the new warnings/errors come from libprocess/stout as there were never any CXXFLAGS propagated to them. https://reviews.apache.org/r/52647/ https://reviews.apache.org/r/52754/ was: Most of the new warnings/errors come from libprocess/stout as there were never any CXXFLAGS propagated to them. https://reviews.apache.org/r/52647/ > Fix warnings and errors produced by new hardened CXXFLAGS > - > > Key: MESOS-6239 > URL: https://issues.apache.org/jira/browse/MESOS-6239 > Project: Mesos > Issue Type: Improvement >Reporter: Aaron Wood >Assignee: Aaron Wood >Priority: Minor > Labels: c++, clang, gcc, libprocess, security, stout > > Most of the new warnings/errors come from libprocess/stout as there were > never any CXXFLAGS propagated to them. > https://reviews.apache.org/r/52647/ > https://reviews.apache.org/r/52754/ -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-6229) Default to using hardened compilation flags
[ https://issues.apache.org/jira/browse/MESOS-6229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aaron Wood updated MESOS-6229: -- Description: Provide a default set of hardened compilation flags to help protect against overflows and other attacks. Apply to libprocess and stout as well. Current set of flags that were discussed on slack to implement: -Wformat-security -Wstack-protector -fstack-protector-strong (-fstack-protector-all might be overkill, it could be more effective to use this. Requires gcc >= 4.9 which should be reasonable) -pie -fPIE -fPIC -D_FORTIFY_SOURCE=2 -Wl,-z,relro,-z,now (currently not a part of the patch) -fno-omit-frame-pointer https://reviews.apache.org/r/52645/ https://reviews.apache.org/r/52695/ https://reviews.apache.org/r/52696/ was: Provide a default set of hardened compilation flags to help protect against overflows and other attacks. Apply to libprocess and stout as well. Current set of flags that were discussed on slack to implement: -Wformat-security -Wstack-protector -fstack-protector-strong (-fstack-protector-all might be overkill, it could be more effective to use this. Requires gcc >= 4.9 which should be reasonable) -pie -fPIE -fPIC -D_FORTIFY_SOURCE=2 -Wl,-z,relro,-z,now (currently not a part of the patch) -fno-omit-frame-pointer https://reviews.apache.org/r/52645/ > Default to using hardened compilation flags > --- > > Key: MESOS-6229 > URL: https://issues.apache.org/jira/browse/MESOS-6229 > Project: Mesos > Issue Type: Improvement >Reporter: Aaron Wood >Assignee: Aaron Wood >Priority: Minor > Labels: c++, clang, gcc, security > > Provide a default set of hardened compilation flags to help protect against > overflows and other attacks. Apply to libprocess and stout as well. Current > set of flags that were discussed on slack to implement: > -Wformat-security > -Wstack-protector > -fstack-protector-strong (-fstack-protector-all might be overkill, it could > be more effective to use this. Requires gcc >= 4.9 which should be reasonable) > -pie > -fPIE > -fPIC > -D_FORTIFY_SOURCE=2 > -Wl,-z,relro,-z,now (currently not a part of the patch) > -fno-omit-frame-pointer > https://reviews.apache.org/r/52645/ > https://reviews.apache.org/r/52695/ > https://reviews.apache.org/r/52696/ -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-6239) Fix warnings and errors produced by new hardened CXXFLAGS
[ https://issues.apache.org/jira/browse/MESOS-6239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aaron Wood updated MESOS-6239: -- Description: Most of the new warnings/errors come from libprocess/stout as there were never any CXXFLAGS propagated to them. https://reviews.apache.org/r/52647/ was:Most of the new warnings/errors come from libprocess/stout as there were never any CXXFLAGS propagated to them. > Fix warnings and errors produced by new hardened CXXFLAGS > - > > Key: MESOS-6239 > URL: https://issues.apache.org/jira/browse/MESOS-6239 > Project: Mesos > Issue Type: Improvement >Reporter: Aaron Wood >Assignee: Aaron Wood >Priority: Minor > Labels: c++, clang, gcc, libprocess, security, stout > > Most of the new warnings/errors come from libprocess/stout as there were > never any CXXFLAGS propagated to them. > https://reviews.apache.org/r/52647/ -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-6229) Default to using hardened compilation flags
[ https://issues.apache.org/jira/browse/MESOS-6229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aaron Wood updated MESOS-6229: -- Description: Provide a default set of hardened compilation flags to help protect against overflows and other attacks. Apply to libprocess and stout as well. Current set of flags that were discussed on slack to implement: -Wformat-security -Wstack-protector -fstack-protector-strong (-fstack-protector-all might be overkill, it could be more effective to use this. Requires gcc >= 4.9 which should be reasonable) -pie -fPIE -fPIC -D_FORTIFY_SOURCE=2 -Wl,-z,relro,-z,now (currently not a part of the patch) -fno-omit-frame-pointer https://reviews.apache.org/r/52645/ was: Provide a default set of hardened compilation flags to help protect against overflows and other attacks. Apply to libprocess and stout as well. Current set of flags that were discussed on slack to implement: -Wformat-security -Wstack-protector -fstack-protector-strong (-fstack-protector-all might be overkill, it could be more effective to use this. Requires gcc >= 4.9) -pie -fPIE -fPIC -D_FORTIFY_SOURCE=2 -Wl,-z,relro,-z,now (currently not a part of the patch) -fno-omit-frame-pointer https://reviews.apache.org/r/52645/ > Default to using hardened compilation flags > --- > > Key: MESOS-6229 > URL: https://issues.apache.org/jira/browse/MESOS-6229 > Project: Mesos > Issue Type: Improvement >Reporter: Aaron Wood >Assignee: Aaron Wood >Priority: Minor > Labels: c++, clang, gcc, security > > Provide a default set of hardened compilation flags to help protect against > overflows and other attacks. Apply to libprocess and stout as well. Current > set of flags that were discussed on slack to implement: > -Wformat-security > -Wstack-protector > -fstack-protector-strong (-fstack-protector-all might be overkill, it could > be more effective to use this. Requires gcc >= 4.9 which should be reasonable) > -pie > -fPIE > -fPIC > -D_FORTIFY_SOURCE=2 > -Wl,-z,relro,-z,now (currently not a part of the patch) > -fno-omit-frame-pointer > https://reviews.apache.org/r/52645/ -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-6229) Default to using hardened compilation flags
[ https://issues.apache.org/jira/browse/MESOS-6229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aaron Wood updated MESOS-6229: -- Description: Provide a default set of hardened compilation flags to help protect against overflows and other attacks. Apply to libprocess and stout as well. Current set of flags that were discussed on slack to implement: -Wformat-security -Wstack-protector -fstack-protector-strong (-fstack-protector-all might be overkill, it could be more effective to use this. Requires gcc >= 4.9) -pie -fPIE -fPIC -D_FORTIFY_SOURCE=2 -Wl,-z,relro,-z,now (currently not a part of the patch) -fno-omit-frame-pointer https://reviews.apache.org/r/52645/ was: Provide a default set of hardened compilation flags to help protect against overflows and other attacks. Apply to libprocess and stout as well. Current set of flags that were discussed on slack to implement: -Wformat-security -Wstack-protector -fstack-protector-strong (-fstack-protector-all might be overkill, it could be more effective to use this. Requires gcc >= 4.9) -pie -fPIE -D_FORTIFY_SOURCE=2 -Wl,-z,relro,-z,now (currently not a part of the patch) -fno-omit-frame-pointer https://reviews.apache.org/r/52645/ > Default to using hardened compilation flags > --- > > Key: MESOS-6229 > URL: https://issues.apache.org/jira/browse/MESOS-6229 > Project: Mesos > Issue Type: Improvement >Reporter: Aaron Wood >Assignee: Aaron Wood >Priority: Minor > Labels: c++, clang, gcc, security > > Provide a default set of hardened compilation flags to help protect against > overflows and other attacks. Apply to libprocess and stout as well. Current > set of flags that were discussed on slack to implement: > -Wformat-security > -Wstack-protector > -fstack-protector-strong (-fstack-protector-all might be overkill, it could > be more effective to use this. Requires gcc >= 4.9) > -pie > -fPIE > -fPIC > -D_FORTIFY_SOURCE=2 > -Wl,-z,relro,-z,now (currently not a part of the patch) > -fno-omit-frame-pointer > https://reviews.apache.org/r/52645/ -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-6229) Default to using hardened compilation flags
[ https://issues.apache.org/jira/browse/MESOS-6229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aaron Wood updated MESOS-6229: -- Description: Provide a default set of hardened compilation flags to help protect against overflows and other attacks. Apply to libprocess and stout as well. Current set of flags that were discussed on slack to implement: -Wformat-security -Wstack-protector -fstack-protector-strong (-fstack-protector-all might be overkill, it could be more effective to use this. Requires gcc >= 4.9) -pie -fPIE -D_FORTIFY_SOURCE=2 -O2 (possibly -O3 for greater optimizations, up for discussion) -Wl,-z,relro,-z,now (currently not a part of the patch) -fno-omit-frame-pointer https://reviews.apache.org/r/52645/ was: Provide a default set of hardened compilation flags to help protect against overflows and other attacks. Apply to libprocess and stout as well. Current set of flags that were discussed on slack to implement: -Wformat-security -Wstack-protector -fstack-protector-all -pie -fPIE -D_FORTIFY_SOURCE=2 -O2 (possibly -O3 for greater optimizations, up for discussion) -Wl,-z,relro,-z,now -fno-omit-frame-pointer -fstack-protector-strong (-fstack-protector-all might be overkill, it could be more effective to use this. Requires gcc >= 4.9) > Default to using hardened compilation flags > --- > > Key: MESOS-6229 > URL: https://issues.apache.org/jira/browse/MESOS-6229 > Project: Mesos > Issue Type: Improvement >Reporter: Aaron Wood >Assignee: Aaron Wood >Priority: Minor > Labels: c++, clang, gcc, security > > Provide a default set of hardened compilation flags to help protect against > overflows and other attacks. Apply to libprocess and stout as well. Current > set of flags that were discussed on slack to implement: > -Wformat-security > -Wstack-protector > -fstack-protector-strong (-fstack-protector-all might be overkill, it could > be more effective to use this. Requires gcc >= 4.9) > -pie > -fPIE > -D_FORTIFY_SOURCE=2 > -O2 (possibly -O3 for greater optimizations, up for discussion) > -Wl,-z,relro,-z,now (currently not a part of the patch) > -fno-omit-frame-pointer > https://reviews.apache.org/r/52645/ -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MESOS-6239) Fix warnings and errors produced by new hardened CXXFLAGS
Aaron Wood created MESOS-6239: - Summary: Fix warnings and errors produced by new hardened CXXFLAGS Key: MESOS-6239 URL: https://issues.apache.org/jira/browse/MESOS-6239 Project: Mesos Issue Type: Improvement Reporter: Aaron Wood Assignee: Aaron Wood Priority: Minor Most of the new warnings/errors come from libprocess/stout as there were never any CXXFLAGS propagated to them. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (MESOS-6229) Default to using hardened compilation flags
[
https://issues.apache.org/jira/browse/MESOS-6229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15517039#comment-15517039
]
Aaron Wood edited comment on MESOS-6229 at 9/23/16 5:48 PM:
Looks like there will need to be some fixes made ahead of time before this
patch goes in (probably many more than this one):
/bin/sh ../../libtool --tag=CXX --mode=compile g++ -DPACKAGE_NAME=\"mesos\"
-DPACKAGE_TARNAME=\"mesos\" -DPACKAGE_VERSION=\"1.1.0\"
-DPACKAGE_STRING=\"mesos\ 1.1.0\" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"\"
-DPACKAGE=\"mesos\" -DVERSION=\"1.1.0\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1
-DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1
-DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1
-DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" -DHAVE_CXX11=1
-DHAVE_PTHREAD_PRIO_INHERIT=1 -DHAVE_PTHREAD=1 -DHAVE_LIBZ=1 -DHAVE_FTS_H=1
-DHAVE_APR_POOLS_H=1 -DHAVE_LIBAPR_1=1 -DHAVE_LIBCURL=1 -DMESOS_HAS_JAVA=1
-DHAVE_PYTHON=\"2.7\" -DMESOS_HAS_PYTHON=1 -DHAVE_LIBSASL2=1
-DHAVE_SVN_VERSION_H=1 -DHAVE_LIBSVN_SUBR_1=1 -DHAVE_SVN_DELTA_H=1
-DHAVE_LIBSVN_DELTA_1=1 -DHAVE_LIBZ=1 -I. -I../../../3rdparty/libprocess
-DBUILD_DIR=\"/Users//Code/src/mesos/build/3rdparty/libprocess\"
-I../../../3rdparty/libprocess/include -isystem ../boost-1.53.0 -I../elfio-3.2
-I../glog-0.3.3/src -I../http-parser-2.6.2 -I../libev-4.22
-DPICOJSON_USE_INT64 -D__STDC_FORMAT_MACROS -I../picojson-1.3.0
-I../../../3rdparty/libprocess/../stout/include
-I/usr/local/opt/subversion/include/subversion-1
-I/usr/local/opt/openssl/include -I/usr/local/opt/libevent/include
-I/usr/include/apr-1 -I/usr/include/apr-1.0 -Wall -Werror -Wsign-compare
-Wformat-security -Wstack-protector -fno-omit-frame-pointer
-fstack-protector-strong -pie -fPIE -D_FORTIFY_SOURCE=2 -O3 -g1 -O0
-Wno-unused-local-typedef -std=c++11 -stdlib=libc++ -DGTEST_USE_OWN_TR1_TUPLE=1
-DGTEST_LANG_CXX11 -MT libprocess_la-reap.lo -MD -MP -MF
.deps/libprocess_la-reap.Tpo -c -o libprocess_la-reap.lo `test -f
'src/reap.cpp' || echo '../../../3rdparty/libprocess/'`src/reap.cpp
../../../3rdparty/libprocess/src/profiler.cpp:35:12: error: unused variable
'PROFILE_FILE' [-Werror,-Wunused-const-variable]
const char PROFILE_FILE[] = "perftools.out";
^
In file included from ../../../3rdparty/libprocess/src/profiler.cpp:24:
../../../3rdparty/libprocess/include/process/profiler.hpp:80:8: error: private
field 'started' is not used [-Werror,-Wunused-private-field]
bool started;
^
2 errors generated.
make[5]: *** [libprocess_la-profiler.lo] Error 1
make[5]: *** Waiting for unfinished jobs
mv -f .deps/libprocess_la-logging.Tpo .deps/libprocess_la-logging.Plo
mv -f .deps/libprocess_la-io.Tpo .deps/libprocess_la-io.Plo
libtool: compile: g++ -DPACKAGE_NAME=\"mesos\" -DPACKAGE_TARNAME=\"mesos\"
-DPACKAGE_VERSION=\"1.1.0\" "-DPACKAGE_STRING=\"mesos 1.1.0\""
-DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"\" -DPACKAGE=\"mesos\"
-DVERSION=\"1.1.0\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1
-DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1
-DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1
-DLT_OBJDIR=\".libs/\" -DHAVE_CXX11=1 -DHAVE_PTHREAD_PRIO_INHERIT=1
-DHAVE_PTHREAD=1 -DHAVE_LIBZ=1 -DHAVE_FTS_H=1 -DHAVE_APR_POOLS_H=1
-DHAVE_LIBAPR_1=1 -DHAVE_LIBCURL=1 -DMESOS_HAS_JAVA=1 -DHAVE_PYTHON=\"2.7\"
-DMESOS_HAS_PYTHON=1 -DHAVE_LIBSASL2=1 -DHAVE_SVN_VERSION_H=1
-DHAVE_LIBSVN_SUBR_1=1 -DHAVE_SVN_DELTA_H=1 -DHAVE_LIBSVN_DELTA_1=1
-DHAVE_LIBZ=1 -I. -I../../../3rdparty/libprocess
-DBUILD_DIR=\"/Users//Code/src/mesos/build/3rdparty/libprocess\"
-I../../../3rdparty/libprocess/include -isystem ../boost-1.53.0 -I../elfio-3.2
-I../glog-0.3.3/src -I../http-parser-2.6.2 -I../libev-4.22 -DPICOJSON_USE_INT64
-D__STDC_FORMAT_MACROS -I../picojson-1.3.0
-I../../../3rdparty/libprocess/../stout/include
-I/usr/local/opt/subversion/include/subversion-1
-I/usr/local/opt/openssl/include -I/usr/local/opt/libevent/include
-I/usr/include/apr-1 -I/usr/include/apr-1.0 -Wall -Werror -Wsign-compare
-Wformat-security -Wstack-protector -fno-omit-frame-pointer
-fstack-protector-strong -D_FORTIFY_SOURCE=2 -O3 -g1 -O0
-Wno-unused-local-typedef -std=c++11 -stdlib=libc++ -DGTEST_USE_OWN_TR1_TUPLE=1
-DGTEST_LANG_CXX11 -MT libprocess_la-reap.lo -MD -MP -MF
.deps/libprocess_la-reap.Tpo -c ../../../3rdparty/libprocess/src/reap.cpp
-fno-common -DPIC -o .libs/libprocess_la-reap.o
In file included from ../../../3rdparty/libprocess/src/process.cpp:108:
../../../3rdparty/libprocess/src/encoder.hpp:278:15: error: comparison of
integers of different signs: 'off_t' (aka 'long long') and 'size_t' (aka
'unsigned long') [-Werror,-Wsign-compare]
if (index >= length) {
~ ^ ~~
../../../3rdparty/libprocess/src/process.cpp:3501:23: error: comparison of
integers of different signs:
[jira] [Commented] (MESOS-6229) Default to using hardened compilation flags
[
https://issues.apache.org/jira/browse/MESOS-6229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15517039#comment-15517039
]
Aaron Wood commented on MESOS-6229:
---
Looks like there will need to be some fixes made ahead of time before this
patch goes in:
```
/bin/sh ../../libtool --tag=CXX --mode=compile g++ -DPACKAGE_NAME=\"mesos\"
-DPACKAGE_TARNAME=\"mesos\" -DPACKAGE_VERSION=\"1.1.0\"
-DPACKAGE_STRING=\"mesos\ 1.1.0\" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"\"
-DPACKAGE=\"mesos\" -DVERSION=\"1.1.0\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1
-DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1
-DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1
-DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" -DHAVE_CXX11=1
-DHAVE_PTHREAD_PRIO_INHERIT=1 -DHAVE_PTHREAD=1 -DHAVE_LIBZ=1 -DHAVE_FTS_H=1
-DHAVE_APR_POOLS_H=1 -DHAVE_LIBAPR_1=1 -DHAVE_LIBCURL=1 -DMESOS_HAS_JAVA=1
-DHAVE_PYTHON=\"2.7\" -DMESOS_HAS_PYTHON=1 -DHAVE_LIBSASL2=1
-DHAVE_SVN_VERSION_H=1 -DHAVE_LIBSVN_SUBR_1=1 -DHAVE_SVN_DELTA_H=1
-DHAVE_LIBSVN_DELTA_1=1 -DHAVE_LIBZ=1 -I. -I../../../3rdparty/libprocess
-DBUILD_DIR=\"/Users//Code/src/mesos/build/3rdparty/libprocess\"
-I../../../3rdparty/libprocess/include -isystem ../boost-1.53.0 -I../elfio-3.2
-I../glog-0.3.3/src -I../http-parser-2.6.2 -I../libev-4.22
-DPICOJSON_USE_INT64 -D__STDC_FORMAT_MACROS -I../picojson-1.3.0
-I../../../3rdparty/libprocess/../stout/include
-I/usr/local/opt/subversion/include/subversion-1
-I/usr/local/opt/openssl/include -I/usr/local/opt/libevent/include
-I/usr/include/apr-1 -I/usr/include/apr-1.0 -Wall -Werror -Wsign-compare
-Wformat-security -Wstack-protector -fno-omit-frame-pointer
-fstack-protector-strong -pie -fPIE -D_FORTIFY_SOURCE=2 -O3 -g1 -O0
-Wno-unused-local-typedef -std=c++11 -stdlib=libc++ -DGTEST_USE_OWN_TR1_TUPLE=1
-DGTEST_LANG_CXX11 -MT libprocess_la-reap.lo -MD -MP -MF
.deps/libprocess_la-reap.Tpo -c -o libprocess_la-reap.lo `test -f
'src/reap.cpp' || echo '../../../3rdparty/libprocess/'`src/reap.cpp
../../../3rdparty/libprocess/src/profiler.cpp:35:12: error: unused variable
'PROFILE_FILE' [-Werror,-Wunused-const-variable]
const char PROFILE_FILE[] = "perftools.out";
^
In file included from ../../../3rdparty/libprocess/src/profiler.cpp:24:
../../../3rdparty/libprocess/include/process/profiler.hpp:80:8: error: private
field 'started' is not used [-Werror,-Wunused-private-field]
bool started;
^
2 errors generated.
make[5]: *** [libprocess_la-profiler.lo] Error 1
make[5]: *** Waiting for unfinished jobs
mv -f .deps/libprocess_la-logging.Tpo .deps/libprocess_la-logging.Plo
mv -f .deps/libprocess_la-io.Tpo .deps/libprocess_la-io.Plo
libtool: compile: g++ -DPACKAGE_NAME=\"mesos\" -DPACKAGE_TARNAME=\"mesos\"
-DPACKAGE_VERSION=\"1.1.0\" "-DPACKAGE_STRING=\"mesos 1.1.0\""
-DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"\" -DPACKAGE=\"mesos\"
-DVERSION=\"1.1.0\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1
-DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1
-DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1
-DLT_OBJDIR=\".libs/\" -DHAVE_CXX11=1 -DHAVE_PTHREAD_PRIO_INHERIT=1
-DHAVE_PTHREAD=1 -DHAVE_LIBZ=1 -DHAVE_FTS_H=1 -DHAVE_APR_POOLS_H=1
-DHAVE_LIBAPR_1=1 -DHAVE_LIBCURL=1 -DMESOS_HAS_JAVA=1 -DHAVE_PYTHON=\"2.7\"
-DMESOS_HAS_PYTHON=1 -DHAVE_LIBSASL2=1 -DHAVE_SVN_VERSION_H=1
-DHAVE_LIBSVN_SUBR_1=1 -DHAVE_SVN_DELTA_H=1 -DHAVE_LIBSVN_DELTA_1=1
-DHAVE_LIBZ=1 -I. -I../../../3rdparty/libprocess
-DBUILD_DIR=\"/Users//Code/src/mesos/build/3rdparty/libprocess\"
-I../../../3rdparty/libprocess/include -isystem ../boost-1.53.0 -I../elfio-3.2
-I../glog-0.3.3/src -I../http-parser-2.6.2 -I../libev-4.22 -DPICOJSON_USE_INT64
-D__STDC_FORMAT_MACROS -I../picojson-1.3.0
-I../../../3rdparty/libprocess/../stout/include
-I/usr/local/opt/subversion/include/subversion-1
-I/usr/local/opt/openssl/include -I/usr/local/opt/libevent/include
-I/usr/include/apr-1 -I/usr/include/apr-1.0 -Wall -Werror -Wsign-compare
-Wformat-security -Wstack-protector -fno-omit-frame-pointer
-fstack-protector-strong -D_FORTIFY_SOURCE=2 -O3 -g1 -O0
-Wno-unused-local-typedef -std=c++11 -stdlib=libc++ -DGTEST_USE_OWN_TR1_TUPLE=1
-DGTEST_LANG_CXX11 -MT libprocess_la-reap.lo -MD -MP -MF
.deps/libprocess_la-reap.Tpo -c ../../../3rdparty/libprocess/src/reap.cpp
-fno-common -DPIC -o .libs/libprocess_la-reap.o
In file included from ../../../3rdparty/libprocess/src/process.cpp:108:
../../../3rdparty/libprocess/src/encoder.hpp:278:15: error: comparison of
integers of different signs: 'off_t' (aka 'long long') and 'size_t' (aka
'unsigned long') [-Werror,-Wsign-compare]
if (index >= length) {
~ ^ ~~
../../../3rdparty/libprocess/src/process.cpp:3501:23: error: comparison of
integers of different signs: 'int' and 'size_type' (aka 'unsigned long')
[-Werror,-Wsign-compare]
for (int i
[jira] [Commented] (MESOS-6229) Default to using hardened compilation flags
[ https://issues.apache.org/jira/browse/MESOS-6229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15514731#comment-15514731 ] Aaron Wood commented on MESOS-6229: --- I think -fstack-protector-all might be way too much. I'm going to benchmark the difference between -fstack-protector and -fstack-protector-strong > Default to using hardened compilation flags > --- > > Key: MESOS-6229 > URL: https://issues.apache.org/jira/browse/MESOS-6229 > Project: Mesos > Issue Type: Improvement >Reporter: Aaron Wood >Assignee: Aaron Wood >Priority: Minor > Labels: c++, clang, gcc, security > > Provide a default set of hardened compilation flags to help protect against > overflows and other attacks. Apply to libprocess and stout as well. Current > set of flags that were discussed on slack to implement: > -Wformat-security > -Wstack-protector > -fstack-protector-all > -pie > -fPIE > -D_FORTIFY_SOURCE=2 > -O2 (possibly -O3 for greater optimizations, up for discussion) > -Wl,-z,relro,-z,now > -fno-omit-frame-pointer > -fstack-protector-strong (-fstack-protector-all might be overkill, it could > be more effective to use this. Requires gcc >= 4.9) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-6229) Default to using hardened compilation flags
[ https://issues.apache.org/jira/browse/MESOS-6229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aaron Wood updated MESOS-6229: -- Description: Provide a default set of hardened compilation flags to help protect against overflows and other attacks. Apply to libprocess and stout as well. Current set of flags that were discussed on slack to implement: -Wformat-security -Wstack-protector -fstack-protector-all -pie -fPIE -D_FORTIFY_SOURCE=2 -O2 (possibly -O3 for greater optimizations, up for discussion) -Wl,-z,relro,-z,now -fno-omit-frame-pointer -fstack-protector-strong (-fstack-protector-all might be overkill, it could be more effective to use this. Requires gcc >= 4.9) was: Provide a default set of hardened compilation flags to help protect against overflows and other attacks. Apply to libprocess and stout as well. Current set of flags that were discussed on slack to implement: -Wformat-security -fstack-protector-all -Wstack-protector -pie -fPIE -D_FORTIFY_SOURCE=2 -O2 -Wl,-z,relro,-z,now -fno-omit-frame-pointer > Default to using hardened compilation flags > --- > > Key: MESOS-6229 > URL: https://issues.apache.org/jira/browse/MESOS-6229 > Project: Mesos > Issue Type: Improvement >Reporter: Aaron Wood >Assignee: Aaron Wood >Priority: Minor > Labels: c++, clang, gcc, security > > Provide a default set of hardened compilation flags to help protect against > overflows and other attacks. Apply to libprocess and stout as well. Current > set of flags that were discussed on slack to implement: > -Wformat-security > -Wstack-protector > -fstack-protector-all > -pie > -fPIE > -D_FORTIFY_SOURCE=2 > -O2 (possibly -O3 for greater optimizations, up for discussion) > -Wl,-z,relro,-z,now > -fno-omit-frame-pointer > -fstack-protector-strong (-fstack-protector-all might be overkill, it could > be more effective to use this. Requires gcc >= 4.9) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-6229) Default to using hardened compilation flags
[ https://issues.apache.org/jira/browse/MESOS-6229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aaron Wood updated MESOS-6229: -- Description: Provide a default set of hardened compilation flags to help protect against overflows and other attacks. Apply to libprocess and stout as well. Current set of flags that were discussed on slack to implement: -Wformat-security -fstack-protector-all -Wstack-protector -pie -fPIE -D_FORTIFY_SOURCE=2 -O2 -Wl,-z,relro,-z,now -fno-omit-frame-pointer was: Provide a default set of hardened compilation flags to help protect against overflows and other attacks. Apply to libprocess and stout as well. Current set of flags that were discussed on slack to implement: -Wformatsecurity -fstack-protector-all -Wstack-protector -pie -fPIE -D_FORTIFY_SOURCE=2 O2 -Wl,-z,relro,-z,now -fno-omit-frame-pointer > Default to using hardened compilation flags > --- > > Key: MESOS-6229 > URL: https://issues.apache.org/jira/browse/MESOS-6229 > Project: Mesos > Issue Type: Improvement >Reporter: Aaron Wood >Assignee: Aaron Wood >Priority: Minor > Labels: c++, clang, gcc, security > > Provide a default set of hardened compilation flags to help protect against > overflows and other attacks. Apply to libprocess and stout as well. Current > set of flags that were discussed on slack to implement: > -Wformat-security > -fstack-protector-all -Wstack-protector > -pie -fPIE > -D_FORTIFY_SOURCE=2 -O2 > -Wl,-z,relro,-z,now > -fno-omit-frame-pointer -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-6229) Default to using hardened compilation flags
[ https://issues.apache.org/jira/browse/MESOS-6229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aaron Wood updated MESOS-6229: -- Description: Provide a default set of hardened compilation flags to help protect against overflows and other attacks. Apply to libprocess and stout as well. Current set of flags that were discussed on slack to implement: -Wformatsecurity -fstack-protector-all -Wstack-protector -pie -fPIE -D_FORTIFY_SOURCE=2 O2 -Wl,-z,relro,-z,now -fno-omit-frame-pointer was:Provide a default set of hardened compilation flags to help protect against overflows and other attacks. Apply to libprocess and stout as well. > Default to using hardened compilation flags > --- > > Key: MESOS-6229 > URL: https://issues.apache.org/jira/browse/MESOS-6229 > Project: Mesos > Issue Type: Improvement >Reporter: Aaron Wood >Assignee: Aaron Wood >Priority: Minor > Labels: c++, clang, gcc, security > > Provide a default set of hardened compilation flags to help protect against > overflows and other attacks. Apply to libprocess and stout as well. Current > set of flags that were discussed on slack to implement: > -Wformatsecurity > -fstack-protector-all -Wstack-protector > -pie -fPIE > -D_FORTIFY_SOURCE=2 O2 > -Wl,-z,relro,-z,now > -fno-omit-frame-pointer -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-6229) Default to using hardened compilation flags
[ https://issues.apache.org/jira/browse/MESOS-6229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aaron Wood updated MESOS-6229: -- Description: Provide a default set of hardened compilation flags to help protect against overflows and other attacks. Apply to libprocess and stout as well. (was: Provide a default set of hardened compilation flags to help protect against overflows and other attacks.) > Default to using hardened compilation flags > --- > > Key: MESOS-6229 > URL: https://issues.apache.org/jira/browse/MESOS-6229 > Project: Mesos > Issue Type: Improvement >Reporter: Aaron Wood >Assignee: Aaron Wood >Priority: Minor > Labels: c++, clang, gcc, security > > Provide a default set of hardened compilation flags to help protect against > overflows and other attacks. Apply to libprocess and stout as well. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MESOS-6229) Default to using hardened compilation flags
Aaron Wood created MESOS-6229: - Summary: Default to using hardened compilation flags Key: MESOS-6229 URL: https://issues.apache.org/jira/browse/MESOS-6229 Project: Mesos Issue Type: Improvement Reporter: Aaron Wood Assignee: Aaron Wood Priority: Minor Provide a default set of hardened compilation flags to help protect against overflows and other attacks. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-6127) Implement suppport for HTTP/2
[ https://issues.apache.org/jira/browse/MESOS-6127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aaron Wood updated MESOS-6127: -- Description: HTTP/2 will allow us to take advantage of connection multiplexing, header compression, streams, server push, etc. Add support for communication over HTTP/2 between masters and agents, framework endpoints, etc. Should we support HTTP/2 without TLS? The spec allows for this but most major browser vendors, libraries, and implementations aren't supporting it unless TLS is used. If we do require TLS, what can be done to reduce the performance hit of the TLS handshake? Might need to change more code to make sure that we are taking advantage of connection sharing so that we can (ideally) only ever have a one-time TLS handshake per shared connection. Some ideas for libs: https://nghttp2.org/documentation/package_README.html - Has encoders/decoders supporting HPACK https://nghttp2.org/documentation/tutorial-hpack.html https://nghttp2.org/documentation/libnghttp2_asio.html - Currently marked as experimental by the nghttp2 docs was: HTTP/2 will allow us to take advantage of connection multiplexing, header compression, streams, server push, etc. Add support for communication over HTTP/2 between masters and agents, framework endpoints, etc. Should we support HTTP/2 without TLS? The spec allows for this but most major browser vendors, libraries, and implementations aren't supporting it unless TLS is used. If we do require TLS, what can be done to reduce the performance hit of the TLS handshake? Might need to change more code to make sure that we are taking advantage of connection sharing so that we can (ideally) only ever have a one-time TLS handshake per shared connection. > Implement suppport for HTTP/2 > - > > Key: MESOS-6127 > URL: https://issues.apache.org/jira/browse/MESOS-6127 > Project: Mesos > Issue Type: Epic > Components: HTTP API, libprocess >Reporter: Aaron Wood > Labels: performance > > HTTP/2 will allow us to take advantage of connection multiplexing, header > compression, streams, server push, etc. Add support for communication over > HTTP/2 between masters and agents, framework endpoints, etc. > Should we support HTTP/2 without TLS? The spec allows for this but most major > browser vendors, libraries, and implementations aren't supporting it unless > TLS is used. If we do require TLS, what can be done to reduce the performance > hit of the TLS handshake? Might need to change more code to make sure that we > are taking advantage of connection sharing so that we can (ideally) only ever > have a one-time TLS handshake per shared connection. > Some ideas for libs: > https://nghttp2.org/documentation/package_README.html - Has encoders/decoders > supporting HPACK https://nghttp2.org/documentation/tutorial-hpack.html > https://nghttp2.org/documentation/libnghttp2_asio.html - Currently marked as > experimental by the nghttp2 docs -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-6127) Implement suppport for HTTP/2
[ https://issues.apache.org/jira/browse/MESOS-6127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15498217#comment-15498217 ] Aaron Wood commented on MESOS-6127: --- Thanks, that would be great! Looks like http-parser still doesn't support HTTP/2. > Implement suppport for HTTP/2 > - > > Key: MESOS-6127 > URL: https://issues.apache.org/jira/browse/MESOS-6127 > Project: Mesos > Issue Type: Epic > Components: HTTP API, libprocess >Reporter: Aaron Wood > Labels: performance > > HTTP/2 will allow us to take advantage of connection multiplexing, header > compression, streams, server push, etc. Add support for communication over > HTTP/2 between masters and agents, framework endpoints, etc. > Should we support HTTP/2 without TLS? The spec allows for this but most major > browser vendors, libraries, and implementations aren't supporting it unless > TLS is used. If we do require TLS, what can be done to reduce the performance > hit of the TLS handshake? Might need to change more code to make sure that we > are taking advantage of connection sharing so that we can (ideally) only ever > have a one-time TLS handshake per shared connection. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-6127) Implement suppport for HTTP/2
[ https://issues.apache.org/jira/browse/MESOS-6127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15497649#comment-15497649 ] Aaron Wood commented on MESOS-6127: --- Sounds good. If you think we should start with HTTP/2 and leave gRPC for later what are your thoughts on using libnghttp2_asio vs. implementing support directly into what exists in http.cpp and http.hpp? There seems to be a lot of custom implementation. > Implement suppport for HTTP/2 > - > > Key: MESOS-6127 > URL: https://issues.apache.org/jira/browse/MESOS-6127 > Project: Mesos > Issue Type: Epic > Components: HTTP API, libprocess >Reporter: Aaron Wood > Labels: performance > > HTTP/2 will allow us to take advantage of connection multiplexing, header > compression, streams, server push, etc. Add support for communication over > HTTP/2 between masters and agents, framework endpoints, etc. > Should we support HTTP/2 without TLS? The spec allows for this but most major > browser vendors, libraries, and implementations aren't supporting it unless > TLS is used. If we do require TLS, what can be done to reduce the performance > hit of the TLS handshake? Might need to change more code to make sure that we > are taking advantage of connection sharing so that we can (ideally) only ever > have a one-time TLS handshake per shared connection. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (MESOS-6127) Implement suppport for HTTP/2
[ https://issues.apache.org/jira/browse/MESOS-6127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15497621#comment-15497621 ] Aaron Wood edited comment on MESOS-6127 at 9/16/16 10:53 PM: - Also, should these changes go upstream https://github.com/3rdparty/libprocess and/or directly in Mesos? was (Author: aaronjwood): Also, should these changes go upstream https://github.com/3rdparty/libprocess and/or directly in Mesos? [~vinodkone] if you think we should start with HTTP/2 and leave gRPC for later what are your thoughts on using libnghttp2_asio vs. implementing support directly into what exists in http.cpp and http.hpp? > Implement suppport for HTTP/2 > - > > Key: MESOS-6127 > URL: https://issues.apache.org/jira/browse/MESOS-6127 > Project: Mesos > Issue Type: Epic > Components: HTTP API, libprocess >Reporter: Aaron Wood > Labels: performance > > HTTP/2 will allow us to take advantage of connection multiplexing, header > compression, streams, server push, etc. Add support for communication over > HTTP/2 between masters and agents, framework endpoints, etc. > Should we support HTTP/2 without TLS? The spec allows for this but most major > browser vendors, libraries, and implementations aren't supporting it unless > TLS is used. If we do require TLS, what can be done to reduce the performance > hit of the TLS handshake? Might need to change more code to make sure that we > are taking advantage of connection sharing so that we can (ideally) only ever > have a one-time TLS handshake per shared connection. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (MESOS-6127) Implement suppport for HTTP/2
[ https://issues.apache.org/jira/browse/MESOS-6127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15497621#comment-15497621 ] Aaron Wood edited comment on MESOS-6127 at 9/16/16 10:53 PM: - Also, should these changes go upstream https://github.com/3rdparty/libprocess and/or directly in Mesos? [~vinodkone] if you think we should start with HTTP/2 and leave gRPC for later what are your thoughts on using libnghttp2_asio vs. implementing support directly into what exists in http.cpp and http.hpp? was (Author: aaronjwood): Also, should these changes go upstream https://github.com/3rdparty/libprocess and/or directly in Mesos? > Implement suppport for HTTP/2 > - > > Key: MESOS-6127 > URL: https://issues.apache.org/jira/browse/MESOS-6127 > Project: Mesos > Issue Type: Epic > Components: HTTP API, libprocess >Reporter: Aaron Wood > Labels: performance > > HTTP/2 will allow us to take advantage of connection multiplexing, header > compression, streams, server push, etc. Add support for communication over > HTTP/2 between masters and agents, framework endpoints, etc. > Should we support HTTP/2 without TLS? The spec allows for this but most major > browser vendors, libraries, and implementations aren't supporting it unless > TLS is used. If we do require TLS, what can be done to reduce the performance > hit of the TLS handshake? Might need to change more code to make sure that we > are taking advantage of connection sharing so that we can (ideally) only ever > have a one-time TLS handshake per shared connection. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
