在 consul 运行状况检查运行后状态"Dead"的 docker 容器

我正在使用consul的healthcheck功能，并且我不断得到这些"死亡"容器:

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

什么是"死亡"容器?一个停止的容器什么时候会变成"死的"?

为了记录，我运行program/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

为什么会发生这种情况?

edit2:找到了:https://github.com/docker/docker/issues/9665

2016年3月更新:issue 9665刚刚被PR 21107关闭(可能针对docker 1.11)
这应该有助于避免"驱动程序aufs未能删除根文件系统"，"设备或资源繁忙"的问题。

2015年5月原答

容器状态

Dead为1，由Container.Start()

测试。

if container.removalInProgress || container.Dead {
        return fmt.Errorf("Container is marked for removal and cannot be started.")
}

当停止失败时设置为Dead，以防止容器重新启动。

故障可能原因参见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有很多bug，特别是在使用devicemapper的时候。

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

相关内容

最新更新

热门标签：