[jira] [Created] (MESOS-4264) DockerContainerizerTest.ROOT_DOCKER_Usage fails when the VM running does not have

["Zhitao Li (JIRA)" <ji...@apache.org>]

Zhitao Li created MESOS-4264:
--------------------------------

             Summary: DockerContainerizerTest.ROOT_DOCKER_Usage fails when the VM running does not have 
                 Key: MESOS-4264
                 URL: https://issues.apache.org/jira/browse/MESOS-4264
             Project: Mesos
          Issue Type: Bug
          Components: docker, test
         Environment: docker: 1.9.1
EC2
kernel: 
{code:none}
$uname  -a
Linux zhitao-jessie 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt11-1+deb8u4 (2015-09-19) x86_64 GNU/Linux

$ mount | grep cgroup
tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,mode=755)
cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,xattr,release_agent=/lib/systemd/systemd-cgroups-agent,name=systemd)
cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,nosuid,nodev,noexec,relatime,cpuset)
cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,cpu,cpuacct)
cgroup on /sys/fs/cgroup/devices type cgroup (rw,nosuid,nodev,noexec,relatime,devices)
cgroup on /sys/fs/cgroup/freezer type cgroup (rw,nosuid,nodev,noexec,relatime,freezer)
cgroup on /sys/fs/cgroup/net_cls,net_prio type cgroup (rw,nosuid,nodev,noexec,relatime,net_cls,net_prio)
cgroup on /sys/fs/cgroup/blkio type cgroup (rw,nosuid,nodev,noexec,relatime,blkio)
cgroup on /sys/fs/cgroup/perf_event type cgroup (rw,nosuid,nodev,noexec,relatime,perf_event)
{code}




            Reporter: Zhitao Li
            Priority: Minor


With debug enabled, seeing following failure when running the tests as root:
{code:none}
[ RUN      ] DockerContainerizerTest.ROOT_DOCKER_Usage
ABORT: (../../3rdparty/libprocess/3rdparty/stout/include/stout/result.hpp:109): Result::get() but state == NONE
*** Aborted at 1451549845 (unix time) try "date -d @1451549845" if you are using GNU date ***
PC: @     0x7f9528ac7107 (unknown)
*** SIGABRT (@0x18be0) received by PID 101344 (TID 0x7f951ef0e700) from PID 101344; stack trace: ***
    @     0x7f9529a788d0 (unknown)
    @     0x7f9528ac7107 (unknown)
    @     0x7f9528ac84e8 (unknown)
    @           0x96dd99 _Abort()
    @           0x96ddc7 _Abort()
    @           0x9c8714 Result<>::get()
    @     0x7f952d871bef mesos::internal::slave::DockerContainerizerProcess::cgroupsStatistics()
    @     0x7f952d870bc2 _ZZN5mesos8internal5slave26DockerContainerizerProcess5usageERKNS_11ContainerIDEENKUliE_clEi
    @     0x7f952d871121 _ZZN5mesos8internal5slave26DockerContainerizerProcess5usageERKNS_11ContainerIDEENKUlRKN6Docker9ContainerEE0_clES9_
    @     0x7f952d877d8d _ZZZNK7process9_DeferredIZN5mesos8internal5slave26DockerContainerizerProcess5usageERKNS1_11ContainerIDEEUlRKN6Docker9ContainerEE0_EcvSt8functionIFT_T0_EEINS_6FutureINS1_18ResourceStatisticsEEESB_EEvENKUlSB_E_clESB_ENKUlvE_clEv
    @     0x7f952d87b8dd _ZNSt17_Function_handlerIFN7process6FutureIN5mesos18ResourceStatisticsEEEvEZZNKS0_9_DeferredIZNS2_8internal5slave26DockerContainerizerProcess5usageERKNS2_11ContainerIDEEUlRKN6Docker9ContainerEE0_EcvSt8functionIFT_T0_EEIS4_SG_EEvENKUlSG_E_clESG_EUlvE_E9_M_invokeERKSt9_Any_data
    @     0x7f952d8ac919 std::function<>::operator()()
    @     0x7f952d8a0b2a _ZZN7process8dispatchIN5mesos18ResourceStatisticsEEENS_6FutureIT_EERKNS_4UPIDERKSt8functionIFS5_vEEENKUlPNS_11ProcessBaseEE_clESF_
    @     0x7f952d8b5bc1 _ZNSt17_Function_handlerIFvPN7process11ProcessBaseEEZNS0_8dispatchIN5mesos18ResourceStatisticsEEENS0_6FutureIT_EERKNS0_4UPIDERKSt8functionIFS9_vEEEUlS2_E_E9_M_invokeERKSt9_Any_dataS2_
    @     0x7f952e16270f std::function<>::operator()()
    @     0x7f952e1479fe process::ProcessBase::visit()
    @     0x7f952e14d9ba process::DispatchEvent::visit()
    @           0x96ed2e process::ProcessBase::serve()
    @     0x7f952e143cda process::ProcessManager::resume()
    @     0x7f952e140ded _ZZN7process14ProcessManager12init_threadsEvENKUlRKSt11atomic_boolE_clES3_
    @     0x7f952e14d17a _ZNSt5_BindIFZN7process14ProcessManager12init_threadsEvEUlRKSt11atomic_boolE_St17reference_wrapperIS3_EEE6__callIvIEILm0EEEET_OSt5tupleIIDpT0_EESt12_Index_tupleIIXspT1_EEE
    @     0x7f952e14d128 _ZNSt5_BindIFZN7process14ProcessManager12init_threadsEvEUlRKSt11atomic_boolE_St17reference_wrapperIS3_EEEclIIEvEET0_DpOT_
    @     0x7f952e14d0b8 _ZNSt12_Bind_simpleIFSt5_BindIFZN7process14ProcessManager12init_threadsEvEUlRKSt11atomic_boolE_St17reference_wrapperIS4_EEEvEE9_M_invokeIIEEEvSt12_Index_tupleIIXspT_EEE
    @     0x7f952e14cffd _ZNSt12_Bind_simpleIFSt5_BindIFZN7process14ProcessManager12init_threadsEvEUlRKSt11atomic_boolE_St17reference_wrapperIS4_EEEvEEclEv
    @     0x7f952e14cf7a _ZNSt6thread5_ImplISt12_Bind_simpleIFSt5_BindIFZN7process14ProcessManager12init_threadsEvEUlRKSt11atomic_boolE_St17reference_wrapperIS6_EEEvEEE6_M_runEv
    @     0x7f9529408970 (unknown)
    @     0x7f9529a710a4 start_thread
    @     0x7f9528b7804d (unknown)
{code}

I believe this is because we don't check {{memCgroup}} is {{SOME}} before using it in {{DockerContainerizerProcess::cgroupsStatistics}} (src/slave/containerizer/docker.cpp:1350)

Maybe there should be a new {{TestFilter}} to check all necessary cgroups are properly mounted?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)