Docker consul healthcheck 运行后状态为 "Dead" 的容器
Docker container with status "Dead" after consul healthcheck runs
我正在使用 consul 的健康检查功能,我不断收到这些 "dead" 容器:
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
20fd397ba638 progrium/consul:latest "\"/bin/bash -c 'cur 15 minutes ago Dead
"Dead" 容器到底是什么?停止的容器什么时候变成"Dead"?
作为记录,我 运行 progrium/consul + gliderlabs/registrator images + SERVICE_XXXX_CHECK 环境变量来做健康检查。它 运行 是一个健康检查脚本 运行 每 X 秒生成一个图像,类似于 docker run --rm my/img healthcheck.sh
我对 "dead" 的一般含义以及如何防止它发生很感兴趣。另一个奇怪的是我的死容器没有名字。
这是集装箱检查的一些信息:
"State": {
"Dead": true,
"Error": "",
"ExitCode": 1,
"FinishedAt": "2015-05-30T19:00:01.814291614Z",
"OOMKilled": false,
"Paused": false,
"Pid": 0,
"Restarting": false,
"Running": false,
"StartedAt": "2015-05-30T18:59:51.739464262Z"
},
奇怪的是,只有时不时地有一个容器死掉并且没有被移除。
谢谢
编辑:
查看日志,我发现是什么导致容器停止失败:
Handler for DELETE /containers/{name:.*} returned error: Cannot destroy container 003876e41429013e46187ebcf6acce1486bc5011435c610bd163b159ba550fbc:
Driver aufs failed to remove root filesystem 003876e41429013e46187ebcf6acce1486bc5011435c610bd163b159ba550fbc:
rename /var/lib/docker/aufs/diff/003876e41429013e46187ebcf6acce1486bc5011435c610bd163b159ba550fbc
/var/lib/docker/aufs/ diff/003876e41429013e46187ebcf6acce1486bc5011435c610bd163b159ba550fbc-removing:
device or resource busy
为什么会这样?
2016 年 3 月更新:issue 9665 has just been closed by PR 21107(可能是 docker 1.11)
这应该有助于避免 "Driver aufs failed to remove root filesystem"、"device or resource busy" 问题。
原始答案 2015 年 5 月
死是一则container states, which is tested by Container.Start()
if container.removalInProgress || container.Dead {
return fmt.Errorf("Container is marked for removal and cannot be started.")
}
它是set Dead when stopping fails,以防止容器重新启动。
在可能的失败原因中,see container.Kill()
。
这意味着 kill -15
和 kill -9
都失败了。
// 1. Send a SIGTERM
if err := container.killPossiblyDeadProcess(15); err != nil {
logrus.Infof("Failed to send SIGTERM to the process, force killing")
if err := container.killPossiblyDeadProcess(9); err != nil {
正如 OP 所提到的,这通常意味着设备或资源繁忙,阻止进程被终止。
EBUSY
导致了很多错误,尤其是在使用 devicemapper
时。
所有 EBUSY
相关问题都有一个跟踪器错误。
见 https://github.com/docker/docker/issues/5684#issuecomment-69052334
我正在使用 consul 的健康检查功能,我不断收到这些 "dead" 容器:
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
20fd397ba638 progrium/consul:latest "\"/bin/bash -c 'cur 15 minutes ago Dead
"Dead" 容器到底是什么?停止的容器什么时候变成"Dead"?
作为记录,我 运行 progrium/consul + gliderlabs/registrator images + SERVICE_XXXX_CHECK 环境变量来做健康检查。它 运行 是一个健康检查脚本 运行 每 X 秒生成一个图像,类似于 docker run --rm my/img healthcheck.sh
我对 "dead" 的一般含义以及如何防止它发生很感兴趣。另一个奇怪的是我的死容器没有名字。
这是集装箱检查的一些信息:
"State": {
"Dead": true,
"Error": "",
"ExitCode": 1,
"FinishedAt": "2015-05-30T19:00:01.814291614Z",
"OOMKilled": false,
"Paused": false,
"Pid": 0,
"Restarting": false,
"Running": false,
"StartedAt": "2015-05-30T18:59:51.739464262Z"
},
奇怪的是,只有时不时地有一个容器死掉并且没有被移除。
谢谢
编辑: 查看日志,我发现是什么导致容器停止失败:
Handler for DELETE /containers/{name:.*} returned error: Cannot destroy container 003876e41429013e46187ebcf6acce1486bc5011435c610bd163b159ba550fbc:
Driver aufs failed to remove root filesystem 003876e41429013e46187ebcf6acce1486bc5011435c610bd163b159ba550fbc:
rename /var/lib/docker/aufs/diff/003876e41429013e46187ebcf6acce1486bc5011435c610bd163b159ba550fbc
/var/lib/docker/aufs/ diff/003876e41429013e46187ebcf6acce1486bc5011435c610bd163b159ba550fbc-removing:
device or resource busy
为什么会这样?
2016 年 3 月更新:issue 9665 has just been closed by PR 21107(可能是 docker 1.11)
这应该有助于避免 "Driver aufs failed to remove root filesystem"、"device or resource busy" 问题。
原始答案 2015 年 5 月
死是一则container states, which is tested by Container.Start()
if container.removalInProgress || container.Dead {
return fmt.Errorf("Container is marked for removal and cannot be started.")
}
它是set Dead when stopping fails,以防止容器重新启动。
在可能的失败原因中,see container.Kill()
。
这意味着 kill -15
和 kill -9
都失败了。
// 1. Send a SIGTERM
if err := container.killPossiblyDeadProcess(15); err != nil {
logrus.Infof("Failed to send SIGTERM to the process, force killing")
if err := container.killPossiblyDeadProcess(9); err != nil {
正如 OP 所提到的,这通常意味着设备或资源繁忙,阻止进程被终止。
EBUSY
导致了很多错误,尤其是在使用 devicemapper
时。
所有 EBUSY
相关问题都有一个跟踪器错误。
见 https://github.com/docker/docker/issues/5684#issuecomment-69052334