状态为“Dead”的Docker容器在Consul健康检查运行之后
我正在使用领事的健康检查function，我一直在收集这些“死”的容器：
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 20fd397ba638 progrium/consul:latest "\"/bin/bash -c 'cur 15 minutes ago Dead 什么是“死”的容器？ 什么时候停止的容器变成“死”？
为了logging，我运行progrium / consul + gliderlabs /注册图像+ SERVICE_XXXX_CHECK envvariables进行健康检查。 它运行一个健康检查脚本，每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
2016年3月更新： 问题9665刚被PR 21107closures（对于docker工1.11可能）
这应该有助于避免“驱动程序aufs无法删除根文件系统”，“设备或资源繁忙”的问题。
原始答案2015年5月
如果容器的状态是Dead，那么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