今天,我使用appcontainers/ MediaWiki docker映像部署了一个MediaWiki实例,现在我遇到了一个新问题,我找不到任何线索。 在尝试使用以下方法附加到mediawiki前端容器后:

docker attach mediawiki_web_1

在我的配置上终止,原因我忽略了,也试着:

docker exec -it mediawiki_web_1 bash

我确实得到了一个接近错误的消息:

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

这就是我的新问题,因为这个容器从未停止重新启动。我可以看到,使用docker ps -a总是返回一个状态重启(127)x秒前。

问题是,我能够停止容器(我测试过),但再次启动它似乎将它带回到重新启动循环中。

知道问题出在哪里吗?整个东西都正常工作,直到我试图把它接上……

我很伤心:-(


当前回答

检查已安装docker的分区。在大多数情况下,分区的容量为100%,因此您可能需要查看这一点。

其他回答

当docker kill CONTAINER_ID无效且docker stop -t 1 CONTAINER_ID也无效时,可以尝试删除容器:

docker container rm CONTAINER_ID

我今天遇到了类似的问题,容器处于持续的重新启动循环中。

在我的案例中,问题与我是一个糟糕的工程师有关。

总之,我通过删除容器、修复代码,然后重新构建并运行容器来解决这个问题。

希望这能帮助将来遇到这个问题的人

尝试运行

docker stop CONTAINER_ID & docker rm -v CONTAINER_ID

谢谢

我忘记了Minikube在后台运行,这总是会重新启动它们

我有这个问题,因为我在一个docker swarm尝试:

docker swarm leave --force

它正在重新启动,状态代码为127,这意味着在容器中有一个丢失的文件/库。启动一个新的容器可能会解决这个问题。

解释:

就我对Docker的理解而言,下面是正在发生的事情:

容器试图启动。在这个过程中,它尝试访问一个不存在的文件/库。 它以127的状态码退出,在这个答案中解释了这一点。 通常,这是容器应该完全退出的地方,但它会重新启动。 它会重新启动,因为重启策略必须被设置为不是no(默认值)的值(使用命令行标志——restart或docker-compose)。Yml键重启),同时启动容器。

解决方案:某些东西可能损坏了容器。理想情况下,启动一个新的容器就可以了。