今天,我使用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容器有问题,不允许它重新启动。所以容器中的某个进程导致重新启动挂起,或者某个进程导致容器在启动时崩溃。

当你启动容器时,如果你要附加到它,请确保你启动它时分离“-d”。(交货。"docker run -d mediawiki_web_1")


docker logs命令将显示容器在非交互式运行时生成的输出。这很可能包括错误消息。

docker logs --tail 50 --follow --timestamps mediawiki_web_1

你也可以用docker run -ti <your_wiki_image>在前台运行一个新容器来看看它做了什么。您可能需要将docker-compose yml中的一些配置映射到docker命令。

我猜附加到媒体维基进程导致崩溃,破坏了数据中的某些东西。


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

docker container rm CONTAINER_ID

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

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

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

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


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

解释:

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

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

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


在我的情况下,nginx容器一直在重新启动,我检查了nginx容器的日志,知道一个不必要的域的.crt和.key文件有错误,所以我删除了各自的.conf文件,.crt和.key,然后重新启动nginx。就是这样,nginx在没有重新启动的情况下正常工作。


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


如果你创建了一个systemd服务,它有:

[Service]
Restart=always
ExecStart=/usr/bin/docker container start -a my_container
ExecStop=/usr/bin/docker container stop -t 2 my_container

首先检查日志容器失败的原因。因为您的重启策略可能会使容器恢复到运行状态。最好是修复这个问题,然后可能你可以建立一个新的映像,有/没有修复。稍后执行以下命令

Docker系统修剪

https://forums.docker.com/t/docker-registry-in-restarting-1-status-forever/12717/3


尝试将这些参数添加到docker yml文件中

restart: "no"
  restart: always
  restart: on-failure
  restart: unless-stopped
  environment:
    POSTGRES_DB: "db_name"
    POSTGRES_HOST_AUTH_METHOD: "trust"

最终文件应该如下所示

postgres:
  restart: "no"
  restart: always
  restart: on-failure
  restart: unless-stopped
  image: postgres:latest
  volumes:
    - /data/postgresql:/var/lib/postgresql
  ports:
    - "5432:5432"
  environment:
    POSTGRES_DB: "db_name"
    POSTGRES_HOST_AUTH_METHOD: "trust"

在我的情况下,我移除了

重启=总

添加

tty: true

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

docker-compose up -d

尝试运行

docker stop CONTAINER_ID & docker rm -v CONTAINER_ID

谢谢


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


在开发中运行了很长一段时间后,在将代码部署到prod服务器后,我遇到了同样的问题 问题是在我的码头写作中。我没有为mongo图像指定一个标记,默认情况下它提取了最新的图像,因为我想保留数据路径,所以mongo版本之间存在不匹配 在dev版本是4.4.3,在prod版本是最新版本(我猜是5.x) 我的解决方案是将映像指定为mongo:4.4.3而不是mongo

我不想走升级DB的路


我只是测试和删除-重启总是和它的工作为我。


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

docker swarm leave --force

我在我的pi4上固定了这个,不知道怎么做。

emby/embyserver_arm32v7:latest -保持重新启动,是否停止,删除重新启动容器,使用:beta

然后尝试ghcr.io/linuxserver/docker-emby/emby:arm32v7-version-4.6.0.3

它没有重新启动,但也没有工作。

停止,rm,然后重试emby/embyserver_arm32v7:latest -现在可以工作了。

不知道为什么。

docker run -d --restart unless-stopped --volume /path/to/programdata:/config --volume /mnt/mydrive:/mnt/share1 --publish 8096:8096 --publish 8920:8920 --env UID=1000 --env GID=100 --env GIDLIST=100 ghcr.io/linuxserver/docker-emby/emby:arm32v7-version-4.6.0.3

我删除了dockers文件夹内的所有文件夹,重新构建所有图像,它对我有用。

 docker-compose up -d --build

and

docker-compose up -d