Docker: คอนเทนเนอร์ยังคงรีสตาร์ทอีกครั้งอีกครั้ง


111

วันนี้ฉันปรับใช้อินสแตนซ์ของ MediaWiki โดยใช้ appcontainers / mediawiki docker image และตอนนี้ฉันมีปัญหาใหม่ซึ่งฉันไม่พบเบาะแสใด ๆ หลังจากพยายามแนบกับคอนเทนเนอร์ด้านหน้าของมีเดียวิกิโดยใช้:

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 ทั้งหมดของฉันโดยใช้forums.docker.com/t/how-to-delete-cache/5753/2 (ฉันเพิ่มแท็ก -f ใน rmi ด้วย) จากนั้นฉันก็สร้างตู้คอนเทนเนอร์ขึ้นมาใหม่และมันก็ใช้งานได้
alberto56

สำหรับฉันมันไม่เพียงพอที่จะลบคอนเทนเนอร์และรูปภาพ (ตามที่อธิบายไว้ในลิงก์ของ @ alberto56) ฉันต้องลบโวลุ่มที่เกี่ยวข้องด้วย เมื่อฉันทำอย่างนั้นฉันก็กลับมาทำธุรกิจ
Katie Byers

คำตอบ:


183

docker logsคำสั่งจะแสดงให้คุณส่งออกภาชนะที่จะสร้างเมื่อคุณไม่ได้เรียกใช้การโต้ตอบ ซึ่งอาจรวมถึงข้อความแสดงข้อผิดพลาด

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

คุณยังสามารถเรียกใช้คอนเทนเนอร์ใหม่ในเบื้องหน้าdocker run -ti <your_wiki_image>เพื่อดูว่าทำอะไรได้บ้าง คุณอาจต้องแมป config บางอย่างจาก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

8
ขอบคุณการเรียกใช้คอนเทนเนอร์ใหม่ได้ผล นักเทียบท่าควรจะทำให้การใช้งานของฉันง่ายขึ้น แต่สำหรับตอนนี้มันเป็นความล้มเหลวครั้งใหญ่ :-) ฉันอาจต้องเรียนรู้และลองเพิ่มเติม ...
Balessan

ฉันกำลังดึงผมออกเพื่อพยายามให้ MySQL ทำงาน docker ps -aแสดงให้ฉันเห็นว่ามันติดอยู่ในลูปสำหรับบูตและคำสั่งของคุณแสดงให้ฉันเห็นว่าทำไม: ไฟล์อยู่ในไดเร็กทอรี mysql ซึ่งไม่สามารถลบได้ คุณช่วยฉันจากการดึงผมออกมาหลายชั่วโมง ขอบคุณ!
Blizzardengle

33

เมื่อdocker kill CONTAINER_IDไม่ทำงานและdocker stop -t 1 CONTAINER_IDไม่ได้ผลคุณสามารถลองลบคอนเทนเนอร์:

docker container rm CONTAINER_ID

วันนี้ฉันมีปัญหาคล้ายกันที่คอนเทนเนอร์อยู่ในลูปรีสตาร์ทอย่างต่อเนื่อง

ปัญหาในกรณีของฉันเกี่ยวข้องกับการที่ฉันเป็นวิศวกรที่ไม่ดี

อย่างไรก็ตามฉันแก้ไขปัญหาโดยการลบคอนเทนเนอร์แก้ไขรหัสของฉันจากนั้นสร้างและเรียกใช้คอนเทนเนอร์ใหม่

หวังว่าสิ่งนี้จะช่วยให้ทุกคนที่ติดอยู่กับปัญหานี้ในอนาคต


4
ฉันใส่รหัสที่ไม่ถูกต้องในแอปพลิเคชันของฉันและในไฟล์นักเทียบท่าของฉันฉันได้เพิ่มrestart: alwaysซึ่งทำให้ฉันตกอยู่ใน
วงล้อม

4

จากประสบการณ์ส่วนตัวดูเหมือนว่ามีปัญหาภายในคอนเทนเนอร์นักเทียบท่าของคุณที่ไม่อนุญาตให้รีสตาร์ท ดังนั้นกระบวนการบางอย่างภายในคอนเทนเนอร์ทำให้การรีสตาร์ทค้างหรือกระบวนการบางอย่างทำให้คอนเทนเนอร์พังเมื่อเริ่มต้น

เมื่อคุณเริ่มคอนเทนเนอร์ให้แน่ใจว่าคุณเริ่มแยก "-d" ถ้าคุณจะแนบกับมัน (เช่น "docker run -d mediawiki_web_1")


ฉันถือว่าใช้งานคอนเทนเนอร์โดยใช้นักเทียบท่าที่แยกออกมาแล้วใช่ไหม หรืออาร์กิวเมนต์ -d หายไปในไฟล์กำหนดค่าของฉัน จะตรวจสอบว่า
Balessan

4

tl; drกำลังรีสตาร์ทด้วยรหัสสถานะ127หมายความว่ามีไฟล์ / ไลบรารีที่หายไปในคอนเทนเนอร์ของคุณ การเริ่มต้นภาชนะใหม่อาจแก้ไขได้

คำอธิบาย:

เท่าที่ฉันเข้าใจ Docker นี่คือสิ่งที่เกิดขึ้น:

  1. คอนเทนเนอร์พยายามเริ่มการทำงาน ในกระบวนการนี้จะพยายามเข้าถึงไฟล์ / ไลบรารีที่ไม่มีอยู่
  2. ออกด้วยรหัสสถานะ127ซึ่งอธิบายไว้ในคำตอบนี้
  3. โดยปกตินี่เป็นจุดที่คอนเทนเนอร์ควรออกอย่างสมบูรณ์ แต่จะรีสตาร์ท
  4. รีสตาร์ทเนื่องจากนโยบายการรีสตาร์ทต้องถูกตั้งค่าเป็นอย่างอื่นที่ไม่ใช่no( ค่าเริ่มต้น ) (โดยใช้แฟล็กบรรทัดคำสั่ง--restartหรือdocker-compose.ymlคีย์restart) ในขณะที่เริ่มต้นคอนเทนเนอร์

วิธีแก้ไข:มีบางอย่างทำให้คอนเทนเนอร์ของคุณเสียหาย การเริ่มต้นภาชนะใหม่ควรทำงานได้ดี


3

อาจเป็นกรณีนี้ได้เช่นกันหากคุณสร้าง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 และ. คีย์จากนั้นเริ่มต้นใหม่ nginx นั่นคือ nginx ทำงานได้ดีโดยไม่ต้องรีสตาร์ท


0

ฉันลืม Minikube ที่ทำงานอยู่เบื้องหลังและนั่นคือสิ่งที่เริ่มต้นใหม่เสมอ


0

ขั้นแรกให้ตรวจสอบบันทึกสาเหตุที่คอนเทนเนอร์ล้มเหลว เนื่องจากนโยบายการรีสตาร์ทของคุณอาจทำให้คอนเทนเนอร์ของคุณกลับสู่สถานะกำลังทำงาน ดีกว่าที่จะแก้ไขปัญหาจากนั้นคุณอาจสร้างภาพใหม่โดยมี / ไม่มีการแก้ไข ต่อมาดำเนินการคำสั่งด้านล่าง

docker system prune

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


0

ลองเพิ่ม params เหล่านี้ในไฟล์ 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"

0

ในกรณีของฉันฉันลบออก

Restart=always

เพิ่มแล้ว

tty: true

และดำเนินการคำสั่งด้านล่างเพื่อเปิดเชลล์ (กระบวนการ daemon เนื่องจากนักเทียบท่าอ่านไฟล์เขียนและหยุดคอนเทนเนอร์เมื่อถึงบรรทัดสุดท้ายของไฟล์)

docker-compose up -d

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.