consul healthcheck 运行后状态为“Dead”的 Docker 容器答案

【问题标题】：Docker container with status "Dead" after consul healthcheck runsconsul healthcheck 运行后状态为“Dead”的 Docker 容器
【发布时间】：2015-05-30 19:29:35
【问题描述】：

我正在使用 consul 的健康检查功能，我不断收到这些“死”容器：

CONTAINER ID  IMAGE                   COMMAND              CREATED         STATUS              PORTS                                                                                                                                                                    NAMES
20fd397ba638  progrium/consul:latest  "\"/bin/bash -c 'cur 15 minutes ago  Dead

究竟什么是“死”容器？停止的容器什么时候会“死亡”？

为了记录，我运行 progrium/consul + gliderlabs/registrator images + SERVICE_XXXX_CHECK 环境变量来进行健康检查。它运行一个运行状况检查脚本，每 X 秒运行一个图像，例如 docker run --rm my/img healthcheck.sh

我一般对“死亡”的含义以及如何防止它发生感兴趣。另一个奇怪的事情是我的死容器没有名字。

这是来自容器检查的一些信息：

  "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

为什么会这样？

编辑2：发现这个：https://github.com/docker/docker/issues/9665

【问题讨论】：

标签： docker consul

【解决方案1】：

2016 年 3 月更新：issue 9665 刚刚被 PR 21107 关闭（可能适用于 docker 1.11）
这应该有助于避免“Driver aufs failed to remove root filesystem”、“device or resource busy”问题。

2015 年 5 月的原始答案

如果container states 则死亡为1，由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 所提到的，设备或资源繁忙，阻止进程被杀死。

【讨论】：

看代码，去找日志，发现了一些东西。我刚刚编辑了主要问题
@TrustNoOne 确实如此。我已经添加了尝试发送终止信号的代码部分。
好吧，我想这个“设备忙”问题还没有解决方案，票仍然是开放和有效的。我会看看其他人有没有话要说，然后接受你的回答，因为它基本上解释了“死”是什么。

【解决方案2】：

EBUSY 引起的 bug 很多，尤其是在使用 devicemapper 时。

所有EBUSY 相关问题都有一个跟踪器错误。见https://github.com/docker/docker/issues/5684#issuecomment-69052334

【讨论】：