Docker : 컨테이너가 계속 다시 시작됨


108

나는 오늘 appcontainers / 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항상 STATUS를 반환하는 사용 을 볼 수 있습니다 Restarting (127) x seconds ago.

문제는 컨테이너를 중지 할 수 있지만 (테스트) 다시 시작하면 다시 시작 루프로 돌아 오는 것 같습니다.

여기서 문제가 뭔지 아세요? 내가 부착하려고 할 때까지 모든 것이 제대로 작동했습니다 ...

나는 슬프다 :-(


forums.docker.com/t/how-to-delete-cache/5753/2를 사용하여 전체 Docker 캐시를 완전히 삭제하여 성공했습니다 (또한 rmi에 -f 태그를 추가했습니다). 그런 다음 컨테이너를 재건하고 작동했습니다.
alberto56

저에게는 컨테이너와 이미지를 삭제하는 것만으로는 충분하지 않았고 (@ alberto56의 링크에 설명 된대로) 관련 볼륨도 삭제해야했습니다. 그 후 다시 사업을 시작했습니다.
케이티 바이어스

답변:


172

docker logs명령은 대화 형으로 실행하지 않을 때 컨테이너가 생성하는 출력을 보여줍니다. 여기에는 오류 메시지가 포함될 수 있습니다.

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

포 그라운드에서 새로운 컨테이너를 실행하여 그 기능을 확인할 수도 있습니다 docker run -ti <your_wiki_image>. docker-composeyml의 일부 구성을 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

7
감사합니다. 새 컨테이너를 실행하면 작업이 완료되었습니다. Docker는 내 배포를 용이하게해야했지만 지금은 큰 실패입니다. :-) 아마도 더 배우고 시도해야 할 것 같습니다 ...
Balessan

나는 MySQL이 작동하도록 노력하고 있었다. docker ps -a부팅 루프에 갇혀 있다는 것을 보여 주었고 명령은 왜 삭제 할 수없는 mysql 디렉토리에 이미있는 파일인지 보여주었습니다. 당신은 내 머리카락을 더 많이 뽑아내는 시간에서 나를 구했습니다. 감사!
Blizzardengle

32

docker kill CONTAINER_ID작동하지 않습니다 docker stop -t 1 CONTAINER_ID하지 작업, 당신은 컨테이너를 삭제하려고 할 수 있습니다 않습니다 또한 :

docker container rm CONTAINER_ID

오늘 컨테이너가 지속적인 재시작 루프에있는 유사한 문제가 발생했습니다.

제 경우의 문제는 제가 가난한 엔지니어라는 것과 관련이 있습니다.

어쨌든 컨테이너를 삭제하고 코드를 수정 한 다음 컨테이너를 다시 빌드하고 실행하여 문제를 해결했습니다.

이것이 앞으로이 문제에 걸린 사람에게 도움이되기를 바랍니다.


4
나는 내 응용 프로그램에 나쁜 코드를 넣었고 내 도커에 내가 추가 restart: always한 파일을 작성 하여 깨진 응용 프로그램을 시작하려고하는 도커 루프에
남았습니다

4

개인적인 경험으로 볼 때 Docker 컨테이너에 문제가있어 다시 시작할 수없는 것 같습니다. 따라서 컨테이너 내의 일부 프로세스로 인해 다시 시작이 중단되거나 일부 프로세스로 인해 컨테이너가 시작시 충돌이 발생합니다.

컨테이너를 시작할 때 컨테이너에 연결하려면 분리 된 "-d"를 시작해야합니다. (예 : "docker run -d mediawiki_web_1")


어쨌든 docker-compose를 사용하여 컨테이너를 실행한다고 가정합니다. 또는 내 구성 파일에 -d 인수가 없습니다. 그것을 확인할 것입니다.
Balessan

4

tl; dr127 컨테이너에 누락 된 파일 / 라이브러리가 있음을 의미 하는 상태 코드로 다시 시작됩니다 . 새 용기를 시작하면 문제가 해결 될 수 있습니다.

설명:

Docker에 대한 나의 이해가 진행되는 한 다음과 같은 일이 발생합니다.

  1. 컨테이너가 시작하려고합니다. 이 과정에서 존재하지 않는 파일 / 라이브러리에 접근을 시도합니다.
  2. 이 답변에127 설명 된 상태 코드로 종료됩니다 .
  3. 일반적으로 컨테이너가 완전히 종료되어야하지만 다시 시작됩니다.
  4. 컨테이너를 시작하는 동안 다시 시작 정책no( default ) 이외의 다른 값으로 설정되어 있어야 하므로 ( 명령 줄 플래그 --restart또는 docker-compose.yml키 사용 restart) 다시 시작됩니다.

솔루션 : 컨테이너가 손상되었을 수 있습니다. 신선한 용기를 시작하는 것이 이상적입니다.


2

다음과 같은 systemd서비스를 생성 한 경우에도 마찬가지 입니다.

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

1

제 경우에는 nginx 컨테이너가 계속 다시 시작되었고, nginx 컨테이너의 로그를 확인하고 불필요한 도메인의 .crt 및 .key 파일에 오류가 있음을 알게되었으므로 각 .conf 파일, .crt 및 .key를 제거한 다음 다시 시작했습니다. nginx. 다시 시작하지 않고 nginx가 제대로 작동합니다.


0

나는 Minikube가 백그라운드에서 실행되는 것을 잊었고 항상 백업을 다시 시작했습니다.



0

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"
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.