Docker stats is not working when a container is using another container's network #21848
Comments
thaJeztah
added
the
kind/bug
|
Thanks for reporting and the clear description and way to reproduce 👍
Can you tell me what isn't working on Docker Beta? |
|
/cc @cpuguy83 you were working on some |
|
Running into this as well. There seems to be an associated error in the docker server logs: |
Sorry for not making this clear @thaJeztah. Starting a container like this |
|
@akalipetis oh, just remembered the Mac beta, is shipping with docker 1.11.0rc3, which contains a bug that doesn't show the memory-limit in stats; it will be fixed in #21853 |
|
I did some investigation and it seems that the issue is located in: In this line, a SandboxID will be I created a pull request #21904 to try to address this issue. |
…er's network. This fix tries to fix the issue in moby#21848 where `docker stats` will not correctly display the container stats in case the container reuse another container's network stack. The issue is that when `stats` is performed, the daemon will check for container network setting's `SandboxID`. Unfortunately, for containers that reuse another container's network stack (`NetworkMode.IsConnected()`), SandboxID is not assigned. Therefore, the daemon thinks the id is invalid and remote API will never return. This fix tries to resolve the SandboxID by iterating through connected containers and identify the appropriate SandboxID. A test case for `stats` remote API has been added to check if `stats` will return within the timeout. This fix fixes moby#21848. Signed-off-by: Yong Tang <yong.tang.github@outlook.com>
|
I'm still seeing this, or what appears to be this, in 1.11.1. Here's the output of my and Environment information:
Steps to reproduce:
Output: Doing |
|
This is only fixed in 1.12. |
|
@cpuguy83 Thanks for the quick response! I'll be on the lookout for a fix in 1.12! |
…er's network. Cherry-pick from upstream (faf2b6f) for 1.10.3 This fix tries to fix the issue in moby#21848 where `docker stats` will not correctly display the container stats in case the container reuse another container's network stack. The issue is that when `stats` is performed, the daemon will check for container network setting's `SandboxID`. Unfortunately, for containers that reuse another container's network stack (`NetworkMode.IsConnected()`), SandboxID is not assigned. Therefore, the daemon thinks the id is invalid and remote API will never return. This fix tries to resolve the SandboxID by iterating through connected containers and identify the appropriate SandboxID. A test case for `stats` remote API has been added to check if `stats` will return within the timeout.
…er's network. This fix tries to fix the issue in moby#21848 where `docker stats` will not correctly display the container stats in case the container reuse another container's network stack. The issue is that when `stats` is performed, the daemon will check for container network setting's `SandboxID`. Unfortunately, for containers that reuse another container's network stack (`NetworkMode.IsConnected()`), SandboxID is not assigned. Therefore, the daemon thinks the id is invalid and remote API will never return. This fix tries to resolve the SandboxID by iterating through connected containers and identify the appropriate SandboxID. A test case for `stats` remote API has been added to check if `stats` will return within the timeout. This fix fixes moby#21848. Signed-off-by: Yong Tang <yong.tang.github@outlook.com>
…er's network. This fix tries to fix the issue in moby#21848 where `docker stats` will not correctly display the container stats in case the container reuse another container's network stack. The issue is that when `stats` is performed, the daemon will check for container network setting's `SandboxID`. Unfortunately, for containers that reuse another container's network stack (`NetworkMode.IsConnected()`), SandboxID is not assigned. Therefore, the daemon thinks the id is invalid and remote API will never return. This fix tries to resolve the SandboxID by iterating through connected containers and identify the appropriate SandboxID. A test case for `stats` remote API has been added to check if `stats` will return within the timeout. This fix fixes moby#21848. Signed-off-by: Yong Tang <yong.tang.github@outlook.com>
|
I'm having the same issue: An environment running CoreOS Alpha (with Docker 1.12), Kubernetes 1.4.6 and Network I/O stats are still not being reported to docker stats command / API. Any idea why this happens? |
Output of
docker version:Output of
docker info:Additional environment details (AWS, VirtualBox, physical, etc.):
Steps to reproduce the issue:
export PAUSE_ID=$(docker run -d -m 10M kubernetes/pause)CHILD_ID=$(docker run -d -m 100M --net container:$PAUSE_ID kubernetes/pause)docker stats $PAUSE_ID $CHILD_IDDescribe the results you received:
The stats of
$CHILD_IDcontainer are all 0s.Describe the results you expected:
The stats of
$CHILD_IDcontainer to be the actual stats it's using.Additional information you deem important (e.g. issue happens only occasionally):
This also happens in my Beta Docker for Mac with version 1.11.0-rc3.
Also, starting a container with
docker run -d -m 100M --net=host kubernetes/pauseseems to be working fine in my AWS machine, but not in my local Docker Beta environment does not correctly show the memory limit in the stats.The text was updated successfully, but these errors were encountered: