[jira] [Commented] (MESOS-9341) Add non-interactive test(s) for `mesos task exec`
[
https://issues.apache.org/jira/browse/MESOS-9341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16672298#comment-16672298
]
Kevin Klues commented on MESOS-9341:
{noformat}
commit 1f574f72486e3adf789ffcf2c8624a3775071979
Author: Armand Grillet
Date: Wed Oct 31 19:07:17 2018 -0400
Added test for interactive 'task exec'.
Review: https://reviews.apache.org/r/69115/
{noformat}
> Add non-interactive test(s) for `mesos task exec`
> -
>
> Key: MESOS-9341
> URL: https://issues.apache.org/jira/browse/MESOS-9341
> Project: Mesos
> Issue Type: Task
> Components: cli
>Reporter: Armand Grillet
>Assignee: Armand Grillet
>Priority: Major
>
> As a source, we could use the tests in
> https://github.com/dcos/dcos-core-cli/blob/b930d2004dceb47090004ab658f35cb608bc70e4/python/lib/dcoscli/tests/integrations/test_task.py
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MESOS-9332) Debug container should run as the same user of its parent container by default
[ https://issues.apache.org/jira/browse/MESOS-9332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16672237#comment-16672237 ] Qian Zhang commented on MESOS-9332: --- RR: https://reviews.apache.org/r/69234/ > Debug container should run as the same user of its parent container by default > -- > > Key: MESOS-9332 > URL: https://issues.apache.org/jira/browse/MESOS-9332 > Project: Mesos > Issue Type: Bug > Components: containerization >Reporter: Qian Zhang >Assignee: Qian Zhang >Priority: Major > Labels: containerizer, mesosphere > > Currently when launching a debug container, by default Mesos agent will use > the executor's user as the debug container's user if the `user` field is not > specified in the debug container's `commandInfo` (see [this > code|https://github.com/apache/mesos/blob/1.7.0/src/slave/http.cpp#L2559] for > details). This is OK for the command task since the command executor's user > is same with command task's user (see [this > code|https://github.com/apache/mesos/blob/1.7.0/src/slave/slave.cpp#L6068:L6070] > for details), so the debug container will be launched as the same user of > the task. But for the task in a task group, the default executor's user is > same with the framework user (see [this > code|https://github.com/apache/mesos/blob/1.7.0/src/slave/slave.cpp#L8959] > for details), so in this case the debug container will be launched as the > same user of the framework rather than the task. So in a scenario that > framework user is a normal user but the task user is root, the debug > container will be launched as the normal which is not desired, the > expectation is the debug container should run as the same user of the > container it debugs. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MESOS-8724) G++ Warning about libc system macros `major` and `minor` prevents Mesos build
[
https://issues.apache.org/jira/browse/MESOS-8724?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16672049#comment-16672049
]
Chun-Hung Hsiao commented on MESOS-8724:
NOTE: This seems to be caused by the change in glibc 2.25:
{noformat}
* The inclusion of by is deprecated. This
means that in a future release, the macros “major”, “minor”, and “makedev”
will only be available from .
These macros are not part of POSIX nor XSI, and their names frequently
collide with user code; see for instance glibc bug 19239 and Red Hat bug
130601. includes under _GNU_SOURCE, and C++ code
presently cannot avoid being compiled under _GNU_SOURCE, exacerbating the
problem.{noformat}
> G++ Warning about libc system macros `major` and `minor` prevents Mesos build
> -
>
> Key: MESOS-8724
> URL: https://issues.apache.org/jira/browse/MESOS-8724
> Project: Mesos
> Issue Type: Bug
>Affects Versions: 1.5.2
>Reporter: Benno Evers
>Assignee: Chun-Hung Hsiao
>Priority: Blocker
> Fix For: 1.6.0
>
>
> On linux systems, the header `` defines three macros called
> makedev(), major() and minor(). (See also
> [http://man7.org/linux/man-pages/man3/makedev.3.html])
> Trying to compile Mesos using g++ 7.2.0 leads to the following warning:
> {noformat}
> ../include/csi/csi.pb.h:6042:13: error: In the GNU C Library, "minor" is
> defined
> by . For historical compatibility, it is
> currently defined by as well, but we plan to
> remove this soon. To use "minor", include
> directly. If you did not intend to use a system-defined macro
> "minor", you should undefine it after including . [-Werror]
> inline ::google::protobuf::uint32 Version::minor() const {
> {noformat}
> The root cause is that csi.proto defines the following protobuf message:
> {noformat}
> message Version {
> uint32 major = 1; // This field is REQUIRED.
> uint32 minor = 2; // This field is REQUIRED.
> uint32 patch = 3; // This field is REQUIRED.
> }
> {noformat}
> The generated C++ in `csi.pb.h` headers will contain, amongst others, the
> following function:
> {noformat}
> #include
> // [6000 lines of code...]
> inline ::google::protobuf::uint32 Version::major() const {
> // @@protoc_insertion_point(field_get:csi.Version.major)
> return major_;
> }
> {noformat}
> And the recursive include structure of the header `` leads to
> `stdlib.h` as follows:
> {noformat}
> . /usr/include/c++/7/string
> .. /usr/include/c++/7/bits/basic_string.h
> ... /usr/include/c++/7/ext/string_conversions.h
> /usr/include/c++/7/cstdlib
> . /usr/include/stdlib.h
> .. /usr/include/x86_64-linux-gnu/sys/types.h
> ... /usr/include/x86_64-linux-gnu/sys/sysmacros.h{noformat}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (MESOS-9366) Test `HealthCheckTest.HealthyTaskNonShell` can hang.
[
https://issues.apache.org/jira/browse/MESOS-9366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16671896#comment-16671896
]
Chun-Hung Hsiao edited comment on MESOS-9366 at 11/1/18 6:46 PM:
-
[~tillt] This hang won't actually manifest unless another bug introduces the
task failures so seems not necessary to backport. That said, I can backport it
if you think this is necessary. [~alexr] WDYT?
was (Author: chhsia0):
[~tillt] This flake won't actually manifest unless another bug introduces the
task failures so seems not necessary to backport. That said, I can backport it
if you think this is necessary. [~alexr] WDYT?
> Test `HealthCheckTest.HealthyTaskNonShell` can hang.
>
>
> Key: MESOS-9366
> URL: https://issues.apache.org/jira/browse/MESOS-9366
> Project: Mesos
> Issue Type: Bug
> Components: test
>Affects Versions: 1.5.0, 1.6.0, 1.7.0
>Reporter: Chun-Hung Hsiao
>Assignee: Chun-Hung Hsiao
>Priority: Major
> Fix For: 1.8.0
>
>
> In {{HealthCheckTest.HealthyTaskNonShell}} the {{statusRunning}} future is
> incorrectly checked before being waited:
> [https://github.com/apache/mesos/blob/d8062f231b9f27889b7cae7a42eef49e4eed79ec/src/tests/health_check_tests.cpp#L673]
> As a result, if for some arbitrary reason there is only one task status
> update sent (e.g., {{TASK_FAILED}}), {{statusRunning->state()}} will make the
> test hang forever:
> {noformat}
> #0 pthread_cond_wait@@GLIBC_2.3.2 () at
> ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
> #1 0x7fc1d9a9991c in
> std::condition_variable::wait(std::unique_lock&) () from
> /usr/lib/x86_64-linux-gnu/libstdc++.so.6
> #2 0x5652770d1950 in synchronized_wait std::mutex> () at ../../3rdparty/stout/include/stout/synchronized.hpp:201
> #3 0x7fc1e76ba909 in process::Gate::wait () at
> ../../../3rdparty/libprocess/src/gate.hpp:50
> #4 0x7fc1e768c01d in process::ProcessManager::wait () at
> ../../../3rdparty/libprocess/src/process.cpp:3232
> #5 0x7fc1e76917fd in process::wait () at
> ../../../3rdparty/libprocess/src/process.cpp:3973
> #6 0x7fc1e75ebf11 in process::Latch::await () at
> ../../../3rdparty/libprocess/src/latch.cpp:63
> #7 0x565275431ff6 in process::Future::await () at
> ../../3rdparty/libprocess/include/process/future.hpp:1289
> #8 0x565275441825 in process::Future::get () at
> ../../3rdparty/libprocess/include/process/future.hpp:1301
> #9 0x565275432198 in process::Future::operator-> () at
> ../../3rdparty/libprocess/include/process/future.hpp:1319
> #10 0x565275db5ef1 in
> mesos::internal::tests::HealthCheckTest_HealthyTaskNonShell_Test::TestBody ()
> at ../../src/tests/health_check_tests.cpp:682
> #11 0x56527717296b in
> testing::internal::HandleSehExceptionsInMethodIfSupported void> () at googletest-release-1.8.0/googletest/src/gtest.cc:2402
> #12 0x56527716ca6b in
> testing::internal::HandleExceptionsInMethodIfSupported
> () at googletest-release-1.8.0/googletest/src/gtest.cc:2438
> #13 0x565277149b82 in testing::Test::Run () at
> googletest-release-1.8.0/googletest/src/gtest.cc:2475
> #14 0x56527714a4a8 in testing::TestInfo::Run () at
> googletest-release-1.8.0/googletest/src/gtest.cc:2656
> #15 0x56527714ab45 in testing::TestCase::Run () at
> googletest-release-1.8.0/googletest/src/gtest.cc:2774
> #16 0x565277151d3e in testing::internal::UnitTestImpl::RunAllTests () at
> googletest-release-1.8.0/googletest/src/gtest.cc:4649
> #17 0x565277173703 in
> testing::internal::HandleSehExceptionsInMethodIfSupported bool> () at googletest-release-1.8.0/googletest/src/gtest.cc:2402
> #18 0x56527716d69d in
> testing::internal::HandleExceptionsInMethodIfSupported bool> () at googletest-release-1.8.0/googletest/src/gtest.cc:2438
> #19 0x5652771508da in testing::UnitTest::Run () at
> googletest-release-1.8.0/googletest/src/gtest.cc:4257
> #20 0x565276034020 in RUN_ALL_TESTS () at
> ../3rdparty/googletest-release-1.8.0/googletest/include/gtest/gtest.h:2233
> #21 0x565276033ab7 in main () at ../../src/tests/main.cpp:168{noformat}
> (The line number above are not correct because of additional logging I added
> to triage this error.)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (MESOS-9367) GetContainers call crashes when using XFS disk isolation.
James Peach created MESOS-9367:
--
Summary: GetContainers call crashes when using XFS disk isolation.
Key: MESOS-9367
URL: https://issues.apache.org/jira/browse/MESOS-9367
Project: Mesos
Issue Type: Bug
Components: agent
Reporter: James Peach
Assignee: James Peach
Here's the check failure:
{noformat}
F1031 20:30:33.246723 3435208 evolve.cpp:736] Check failed:
'::protobuf::parse(resource_statistics.get())' Must be
SOME: Missing required fields: disk_statistics[0].source.type
{noformat}
The JSON that is being rendered into protobufs is:
{noformat}
"disk_statistics": [
{
"limit_bytes": 41943040,
"persistence": {
"id": "7461819b-b0bf-42fc-aa9e-f9958c545523",
"principal": "jarvis-principal"
},
"source": {},
"used_bytes": 25006080
}
],
{noformat}
Note the empty "source" element, which triggers the protobuf conversion failure.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MESOS-9366) Test `HealthCheckTest.HealthyTaskNonShell` can hang.
[
https://issues.apache.org/jira/browse/MESOS-9366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16671896#comment-16671896
]
Chun-Hung Hsiao commented on MESOS-9366:
[~tillt] This flake won't actually manifest unless another bug introduces the
task failures so seems not necessary to backport. That said, I can backport it
if you think this is necessary. [~alexr] WDYT?
> Test `HealthCheckTest.HealthyTaskNonShell` can hang.
>
>
> Key: MESOS-9366
> URL: https://issues.apache.org/jira/browse/MESOS-9366
> Project: Mesos
> Issue Type: Bug
> Components: test
>Affects Versions: 1.5.0, 1.6.0, 1.7.0
>Reporter: Chun-Hung Hsiao
>Assignee: Chun-Hung Hsiao
>Priority: Major
> Labels: flaky-test
> Fix For: 1.8.0
>
>
> In {{HealthCheckTest.HealthyTaskNonShell}} the {{statusRunning}} future is
> incorrectly checked before being waited:
> [https://github.com/apache/mesos/blob/d8062f231b9f27889b7cae7a42eef49e4eed79ec/src/tests/health_check_tests.cpp#L673]
> As a result, if for some arbitrary reason there is only one task status
> update sent (e.g., {{TASK_FAILED}}), {{statusRunning->state()}} will make the
> test hang forever:
> {noformat}
> #0 pthread_cond_wait@@GLIBC_2.3.2 () at
> ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
> #1 0x7fc1d9a9991c in
> std::condition_variable::wait(std::unique_lock&) () from
> /usr/lib/x86_64-linux-gnu/libstdc++.so.6
> #2 0x5652770d1950 in synchronized_wait std::mutex> () at ../../3rdparty/stout/include/stout/synchronized.hpp:201
> #3 0x7fc1e76ba909 in process::Gate::wait () at
> ../../../3rdparty/libprocess/src/gate.hpp:50
> #4 0x7fc1e768c01d in process::ProcessManager::wait () at
> ../../../3rdparty/libprocess/src/process.cpp:3232
> #5 0x7fc1e76917fd in process::wait () at
> ../../../3rdparty/libprocess/src/process.cpp:3973
> #6 0x7fc1e75ebf11 in process::Latch::await () at
> ../../../3rdparty/libprocess/src/latch.cpp:63
> #7 0x565275431ff6 in process::Future::await () at
> ../../3rdparty/libprocess/include/process/future.hpp:1289
> #8 0x565275441825 in process::Future::get () at
> ../../3rdparty/libprocess/include/process/future.hpp:1301
> #9 0x565275432198 in process::Future::operator-> () at
> ../../3rdparty/libprocess/include/process/future.hpp:1319
> #10 0x565275db5ef1 in
> mesos::internal::tests::HealthCheckTest_HealthyTaskNonShell_Test::TestBody ()
> at ../../src/tests/health_check_tests.cpp:682
> #11 0x56527717296b in
> testing::internal::HandleSehExceptionsInMethodIfSupported void> () at googletest-release-1.8.0/googletest/src/gtest.cc:2402
> #12 0x56527716ca6b in
> testing::internal::HandleExceptionsInMethodIfSupported
> () at googletest-release-1.8.0/googletest/src/gtest.cc:2438
> #13 0x565277149b82 in testing::Test::Run () at
> googletest-release-1.8.0/googletest/src/gtest.cc:2475
> #14 0x56527714a4a8 in testing::TestInfo::Run () at
> googletest-release-1.8.0/googletest/src/gtest.cc:2656
> #15 0x56527714ab45 in testing::TestCase::Run () at
> googletest-release-1.8.0/googletest/src/gtest.cc:2774
> #16 0x565277151d3e in testing::internal::UnitTestImpl::RunAllTests () at
> googletest-release-1.8.0/googletest/src/gtest.cc:4649
> #17 0x565277173703 in
> testing::internal::HandleSehExceptionsInMethodIfSupported bool> () at googletest-release-1.8.0/googletest/src/gtest.cc:2402
> #18 0x56527716d69d in
> testing::internal::HandleExceptionsInMethodIfSupported bool> () at googletest-release-1.8.0/googletest/src/gtest.cc:2438
> #19 0x5652771508da in testing::UnitTest::Run () at
> googletest-release-1.8.0/googletest/src/gtest.cc:4257
> #20 0x565276034020 in RUN_ALL_TESTS () at
> ../3rdparty/googletest-release-1.8.0/googletest/include/gtest/gtest.h:2233
> #21 0x565276033ab7 in main () at ../../src/tests/main.cpp:168{noformat}
> (The line number above are not correct because of additional logging I added
> to triage this error.)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MESOS-9366) Test `HealthCheckTest.HealthyTaskNonShell` can hang.
[
https://issues.apache.org/jira/browse/MESOS-9366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16671820#comment-16671820
]
Till Toenshoff commented on MESOS-9366:
---
Can we consider back porting the fix, given that it appears to be rather
straight forward and risk free?
> Test `HealthCheckTest.HealthyTaskNonShell` can hang.
>
>
> Key: MESOS-9366
> URL: https://issues.apache.org/jira/browse/MESOS-9366
> Project: Mesos
> Issue Type: Bug
> Components: test
>Affects Versions: 1.5.0, 1.6.0, 1.7.0
>Reporter: Chun-Hung Hsiao
>Assignee: Chun-Hung Hsiao
>Priority: Major
> Labels: flaky-test
>
> In {{HealthCheckTest.HealthyTaskNonShell}} the {{statusRunning}} future is
> incorrectly checked before being waited:
> [https://github.com/apache/mesos/blob/d8062f231b9f27889b7cae7a42eef49e4eed79ec/src/tests/health_check_tests.cpp#L673]
> As a result, if for some arbitrary reason there is only one task status
> update sent (e.g., {{TASK_FAILED}}), {{statusRunning->state()}} will make the
> test hang forever:
> {noformat}
> #0 pthread_cond_wait@@GLIBC_2.3.2 () at
> ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
> #1 0x7fc1d9a9991c in
> std::condition_variable::wait(std::unique_lock&) () from
> /usr/lib/x86_64-linux-gnu/libstdc++.so.6
> #2 0x5652770d1950 in synchronized_wait std::mutex> () at ../../3rdparty/stout/include/stout/synchronized.hpp:201
> #3 0x7fc1e76ba909 in process::Gate::wait () at
> ../../../3rdparty/libprocess/src/gate.hpp:50
> #4 0x7fc1e768c01d in process::ProcessManager::wait () at
> ../../../3rdparty/libprocess/src/process.cpp:3232
> #5 0x7fc1e76917fd in process::wait () at
> ../../../3rdparty/libprocess/src/process.cpp:3973
> #6 0x7fc1e75ebf11 in process::Latch::await () at
> ../../../3rdparty/libprocess/src/latch.cpp:63
> #7 0x565275431ff6 in process::Future::await () at
> ../../3rdparty/libprocess/include/process/future.hpp:1289
> #8 0x565275441825 in process::Future::get () at
> ../../3rdparty/libprocess/include/process/future.hpp:1301
> #9 0x565275432198 in process::Future::operator-> () at
> ../../3rdparty/libprocess/include/process/future.hpp:1319
> #10 0x565275db5ef1 in
> mesos::internal::tests::HealthCheckTest_HealthyTaskNonShell_Test::TestBody ()
> at ../../src/tests/health_check_tests.cpp:682
> #11 0x56527717296b in
> testing::internal::HandleSehExceptionsInMethodIfSupported void> () at googletest-release-1.8.0/googletest/src/gtest.cc:2402
> #12 0x56527716ca6b in
> testing::internal::HandleExceptionsInMethodIfSupported
> () at googletest-release-1.8.0/googletest/src/gtest.cc:2438
> #13 0x565277149b82 in testing::Test::Run () at
> googletest-release-1.8.0/googletest/src/gtest.cc:2475
> #14 0x56527714a4a8 in testing::TestInfo::Run () at
> googletest-release-1.8.0/googletest/src/gtest.cc:2656
> #15 0x56527714ab45 in testing::TestCase::Run () at
> googletest-release-1.8.0/googletest/src/gtest.cc:2774
> #16 0x565277151d3e in testing::internal::UnitTestImpl::RunAllTests () at
> googletest-release-1.8.0/googletest/src/gtest.cc:4649
> #17 0x565277173703 in
> testing::internal::HandleSehExceptionsInMethodIfSupported bool> () at googletest-release-1.8.0/googletest/src/gtest.cc:2402
> #18 0x56527716d69d in
> testing::internal::HandleExceptionsInMethodIfSupported bool> () at googletest-release-1.8.0/googletest/src/gtest.cc:2438
> #19 0x5652771508da in testing::UnitTest::Run () at
> googletest-release-1.8.0/googletest/src/gtest.cc:4257
> #20 0x565276034020 in RUN_ALL_TESTS () at
> ../3rdparty/googletest-release-1.8.0/googletest/include/gtest/gtest.h:2233
> #21 0x565276033ab7 in main () at ../../src/tests/main.cpp:168{noformat}
> (The line number above are not correct because of additional logging I added
> to triage this error.)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
