logo标签列表

Docker：容器一再重启

docker
219

我今天使用 appcontainers/mediawiki docker 镜像部署了一个 MediaWiki 实例，现在我遇到了一个新的问题，但是我找不到任何线索。在尝试使用以下命令连接到 MediaWiki 前端容器后：

docker attach mediawiki_web_1

我不知道原因，我的配置出现了Terminated的错误提示，我还尝试了其他方法：

docker exec -it mediawiki_web_1 bash

我确实收到了接近错误信息的内容：

Error response from daemon: Container 81c07e4a69519c785b12ce4512a8ec76a10231ecfb30522e714b0ae53a0c9c68 is restarting, wait until the container is running

我的新问题是，这个容器始终不停地重新启动。我可以使用docker ps -a命令查看其状态，它总是返回一个Restarting (127) x seconds ago的状态。

问题是，我能够停止该容器（我测试过了），但是再次启动它似乎会使它回到重新启动的循环中。

你知道这里可能有什么问题吗？在我尝试连接到容器之前，整个程序都是正常工作的......

我很难过 :-(

我通过完全删除我的整个Docker缓存（使用https://forums.docker.com/t/how-to-delete-cache/5753/2）取得了成功（我还在rmi中添加了-f标记）。然后我重建了我的容器，它们就正常工作了。 - alberto56
对我来说，仅删除容器和镜像（如@alberto56链接中所述）是不够的，我还必须删除相关联的卷。一旦我这样做了，我就可以恢复正常工作了。 - Katie Byers
18个回答
330
docker logs 命令将显示容器在非交互式运行时生成的输出内容，其中很可能包含错误信息。
docker logs --tail 50 --follow --timestamps mediawiki_web_1

您还可以使用docker run -ti <your_wiki_image>在前台运行一个新的容器，以查看其效果。您可能需要将一些配置映射从docker-compose yml到docker命令。

我猜附加到媒体维基进程导致崩溃，这可能已经破坏了数据中的某些内容。

您提供的命令结果，我猜测是获取与容器相关的最后50个日志，结果如下： 2016-05-26T16:38:27.362409489Z * Stopping web server apache2 * 2016-05-26T21:49:11.376549083Z Terminated 2016-05-26T21:49:11.688655642Z /bin/bash: /tmp/.runconfig.sh: No such file or directory，所以你说得对，数据中有一些损坏，因为runconfig.sh似乎已经消失了。我会按照你的建议再次尝试在前台运行容器。只需要找到如何指定25个正确的参数即可。 - Balessan
13
谢谢，运行一个新的容器解决了问题。Docker应该简化我的部署，但目前它是一个巨大的失败 :-) 我可能需要学习并尝试更多... - Balessan
我一直在为让MySQL正常工作而苦恼。docker ps -a 命令告诉我它陷入了一个启动循环，而你的命令则告诉我原因：有些文件已经存在于mysql目录中，但无法删除。你帮我节省了数小时的烦恼。谢谢！ - Blizzardengle
谢谢，实际上容器本身有一些要求，这帮助调试了缺失的内容，非常有帮助。 - justnajm
46
当使用 docker kill CONTAINER_ID 命令无法生效，且 docker stop -t 1 CONTAINER_ID 命令也无法生效时，你可以尝试删除容器：
docker container rm CONTAINER_ID

今天我遇到了类似的问题，容器一直在重启循环中。根据我的经验，这个问题与我的工程能力不足有关。我解决了这个问题，通过删除容器、修复代码，然后重新构建和运行容器。希望这可以帮助将来遇到同样问题的人。
5
我在应用程序中放入了糟糕的代码，并在我的Docker Compose文件中添加了restart: always，这使我陷入了Docker不断尝试启动损坏应用程序的循环中... :( - Giannis Katsini
1
啊，我看到你是个可怜的工程师，我也是一个可怜的工程师，在我的代码中不小心加了 exit()。 - jscul
15

在我的情况下，我移除了

Restart=always

然后添加了

tty: true

执行以下命令打开shell（守护进程，因为docker读取compose文件并在达到文件的最后一行时停止容器）。

docker-compose up -d
在我的情况下，每一步都是有意义的。 - Mihir Bhatt
11

我遇到了这个问题，因为我正在尝试使用 Docker Swarm：

docker swarm leave --force
先生，您是赢家 :-) - blissweb
1
使用docker service ls命令可以查看现有Swarm中的服务。而使用docker service rm命令则是与完全离开Swarm相比的另一种解决方案。 - Raman
10

简述： 容器以状态码 127 重新启动，这意味着容器中缺少文件或库。尝试使用全新的容器来解决问题。

解释：

依据我对 Docker 的理解，以下是发生的情况：

  1. 容器正在启动时，尝试访问一个不存在的文件或库。
  2. 它以状态码 127 退出，这在此答案中有解释。
  3. 通常情况下，容器应该完全退出，但是它重新启动了。
  4. 它重新启动是因为重启策略必须设置为不同于默认值no（可以使用命令行标志--restart或docker-compose.yml键restart来设置），当启动容器时。

解决方法：可能会出现容器损坏的情况，建议尝试使用全新的容器来解决问题。

7
这也可能是因为您创建了一个 systemd 服务，其中包含以下内容：
[Service]
Restart=always
ExecStart=/usr/bin/docker container start -a my_container
ExecStop=/usr/bin/docker container stop -t 2 my_container
6

根据个人经验，似乎您的Docker容器存在问题，导致它无法重新启动。因此，容器内的某些进程会导致重新启动挂起，或者某些进程会导致容器在启动时崩溃。

当您启动容器时，请确保使用“-d”分离模式启动它，如果您要附加到它，请使用以下命令：（例如，“docker run -d mediawiki_web_1”）

我假设使用docker-compose运行容器时已经以分离模式运行了，是吗？或者我的配置文件中缺少-d参数。我会检查一下。 - Balessan
3
在将代码部署到生产服务器后，我遇到了同样的问题，这是在长时间运行开发环境后出现的。问题在于我的docker-compose.yml文件中没有为mongo镜像指定标签，默认情况下它会拉取最新版本，由于我想保留数据路径，所以mongo版本不匹配，在开发环境中是4.4.3，在生产环境中则拉取了最新版本（我猜是5.x）。对我来说解决方案是将镜像指定为mongo:4.4.3而不仅仅是mongo。
我不想升级数据库。
2

在我的情况下，nginx容器一直在重新启动，我检查了nginx容器的日志并知道一个不必要的域名的.crt和.key文件有错误，因此我删除了相应的.conf文件，.crt和.key文件，然后重新启动nginx。这样nginx就可以正常工作而无需重新启动。

1
你说得完全正确，修复问题确实比其他答案更好。有所帮助的是展示如何找到日志文件，因为容器一直在重新启动，所以日志文件消失了。仅仅删除重启参数也无济于事，因为当容器失败时，日志文件仍然会消失。如果您更新了此信息，则我认为您将获得更多的赞同。 - Sevak Avakians
网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接