docker容器无法启动，因为现有的pid文件

Question

当我启动一个docker容器时，它失败了，因为一个现有的pid文件：

[root@newhope sergio]# docker logs sharp_shockley 
httpd (pid 1) already running
httpd (pid 1) already running
httpd (pid 1) already running
httpd (pid 1) already running

我怎么能删除这样的文件，因为我找不到它。

[root@newhope sergio]# docker version
Client version: 1.4.1
Client API version: 1.16
Go version (client): go1.3.3
Git commit (client): 5bc2ff8/1.4.1
OS/Arch (client): linux/amd64
Server version: 1.4.1
Server API version: 1.16
Go version (server): go1.3.3
Git commit (server): 5bc2ff8/1.4.1

[root@newhope sergio]# find / -name "httpd.pid"
find: ‘/run/user/1000/gvfs’: Permiso denegado

Answer 1

尝试：

docker-compose down

销毁任何已在运行的环境。

Answer 2

在经历了太多的挫折之后，我在我坏了的字母表容器中解决了这个问题：

您必须知道http pid文件的名称/路径是什么。在下面的示例中，它位于容器内的/run/apache2/apache2.pid。完成后，您可以运行以下命令：

docker start [container_id]; docker exec [container_id] rm /run/apache2/apache2.pid

这样做的目的是启动容器，然后立即尝试运行命令来删除PID文件--希望在应该启动的进程docker出现故障之前。如果您的容器进程不能快速运行，这可能对您不起作用。试着运行它几次，你可能会抢先一步。

为了找到我的PID文件的位置，我执行了类似于@sebelk的操作，但我没有展开tar文件，而是列出了它的内容并查找正确的filename...like，从而节省了一些时间，因此：

docker export [container_id] > /tmp/brokecontainercontents.tar
tar -tf /tmp/brokecontainercontents.tar | less 

这很愚蠢，而且可能有一种更好的方法来查看容器的内容。理想情况下，您可以通过其他方式找到PID文件的名称(欢迎使用注释！)。

顿悟

上面的答案是有用的，但我现在意识到，我和这里的许多其他人在基本层面上误解了Docker。事实上，@styonsk下面被否决的答案是正确的。而且，@avijendr对它的批判性评论也是正确的:这将销毁容器中的数据--但这无关紧要。我会解释的。

我最初被告知Docker“像chroot，但更好”。这是事实，但具有误导性。在chroot监狱中，您的数据存储在监狱中(当然是这样，否则被监禁的进程会如何看到它？)因此，当我开始使用Docker时，我认为卷功能是获取容器中数据的一种方式--您可以将卷挂载到本地系统并查看其中的内容。当我尝试这样做时，我真的被惹恼了，因为这就好像容器丢失了我所有的数据--容器应用程序是这样运行的，并且在本地挂载的位置上没有任何东西！错错了错了。

Docker中的卷将您的本地数据/文件挂载到容器中，而不是反过来。因此，当我将卷挂载到一个空的本地目录中(期望容器中的文件出现)时，空的本地目录被挂载到容器中，隐藏了容器中存在的文件，并使应用程序看起来像是丢失了数据(因为它确实丢失了)。实际上，Docker容器在没有安装Volume的情况下工作的事实是一个副作用，可以说是一个有害的副作用。这不是它想要的工作方式。任何写入到容器中的卷位置的数据都应该是可处理的！

(顺便说一句，我开始使用Docker时使用的是Kitematic，它可以在一步内拉取、创建和启动一个容器，而无需询问您想要将卷挂载到何处，这是我产生错误想法的一部分原因……我现在个人认为，除非您已经在某个地方挂载了卷，或者明确决定不这样做，否则它不应该启动容器。)

因此，Docker容器的预期用途通常是(也应该是)在容器内运行应用程序，该应用程序作用于容器外部的数据，即挂载到本地系统的卷中。这意味着，如果容器出现问题，您应该能够销毁它，并启动装载到相同卷的另一个副本--您可以找回所有数据，因为它一开始就不在容器中。

因此，@styonsk的答案是正确的:如果你正确使用Docker，你应该能够销毁容器并启动一个新的容器。一方面，这听起来有点杀伤力，但另一方面，容器化应用程序的要点是，您不需要知道它内部发生了什么，而且可以说您不知道……您如何知道在不干净的关机后唯一损坏的是httpd.pid文件还在那里？可能会有更多你不知道的混乱！可以说，这就是抽象的目的。

如果该模型不适用于您的用例--或者您只是不喜欢它--答案可能是您不应该使用Docker容器。这也不是一件坏事，只是你可能想把扁平头螺丝钉装进一个十字螺丝钉里。您可能只需要一个轻量级的全栈VM环境。

Answer 3

重建/重建可能会有所帮助。docker-compose up --build --force-recreate <service-name>

此外，主机(物理服务器)可能没有剩余的磁盘空间。