“Container exited”: Logs lesen und Crashloops beheben

Container, die sofort nach dem Start wieder beendet werden, sind ein häufiges Problem beim Arbeiten mit Docker. Ein typisches Szenario ist der Status Exited oder ein sogenannter Crashloop, bei dem der Container immer wieder startet und abstürzt. In diesem Artikel zeigen wir, wie Sie Logs analysieren, Fehlerquellen identifizieren und Crashloops zuverlässig beheben können.

Container Status prüfen

Um zu sehen, welche Container kürzlich beendet wurden, nutzen Sie:

docker ps -a
# Ausgabe:
# CONTAINER ID   IMAGE           COMMAND                  STATUS                      PORTS   NAMES
# 1a2b3c4d5e6f   myapp:latest    "python app.py"          Exited (1) 2 minutes ago         myapp_container

• Der Status Exited (1) gibt den Exit-Code des Containers zurück.
• Ein Exit-Code ≠ 0 signalisiert einen Fehler im Container-Prozess.
• Crashloops entstehen häufig bei fehlerhaften Startbefehlen oder Konfigurationsproblemen.

Logs auslesen

Die einfachste Methode, den Grund für das Beenden zu erkennen, ist das Lesen der Container-Logs:

docker logs myapp_container

• Zeigt stdout/stderr-Ausgaben des Container-Prozesses
• Oft finden sich hier Exceptions, Fehlermeldungen oder fehlende Dateien
• Für kontinuierliches Monitoring kann docker logs -f myapp_container verwendet werden

Exit Codes interpretieren

Docker-Container nutzen Exit-Codes, um den Status zu kommunizieren:

• 0 – Normal beendet
• 1 – Allgemeiner Fehler
• 137 – Container wurde vom Kernel mit SIGKILL beendet (z. B. wegen OOM)
• 143 – Container erhielt SIGTERM und wurde sauber beendet
• Weitere Codes können abhängig vom Anwendungscode sein

docker inspect myapp_container --format='{{.State.ExitCode}}'

Crashloop-Ursachen

1. Fehlerhafte Startbefehle

Der Container-Befehl (CMD oder ENTRYPOINT) kann fehlerhaft sein oder benötigte Dateien fehlen:

FROM python:3.11
COPY app.py /app/
WORKDIR /app
CMD ["python", "app.py"]

• Fehlt app.py, bricht der Container sofort ab
• Prüfen Sie die Pfade und Dateinamen im Image

2. Fehlende Umgebungsvariablen oder Secrets

Viele Anwendungen erwarten bestimmte Umgebungsvariablen:

docker run -e DB_HOST=db -e DB_USER=root myapp:latest

• Fehlt eine Variable, kann der Startprozess mit Exit-Code 1 abbrechen
• In Compose-Dateien über environment oder secrets definieren

3. Berechtigungsprobleme

Volumes oder Bind-Mounts können falsche UID/GID haben:

docker run -v ./data:/app/data myapp:latest

• Container kann nicht auf /app/data schreiben → Exit
• Host-Berechtigungen prüfen: ls -l ./data
• Optional: chown -R 1000:1000 ./data

4. Ressourcenlimitierungen

Container, die zu wenig RAM oder CPU zugewiesen bekommen, können vom Kernel beendet werden:

docker run --memory="256m" myapp:latest

• OOM (Out-of-Memory) führt zu Exit-Code 137
• Überprüfen mit dmesg oder docker stats

5. Abhängigkeiten und Netzwerk

Wenn ein Service eine Datenbank oder API erwartet, die noch nicht bereit ist, kann der Container abstürzen:

docker-compose up
# web hängt von db ab
depends_on:
  - db

• depends_on steuert nur Startreihenfolge, prüft keine Verfügbarkeit
• Healthchecks helfen, Start zu verzögern, bis abhängige Dienste bereit sind

Tools zum Troubleshooting

• docker logs -f – Echtzeit-Logs
• docker inspect – Details zu Status, Netzwerken, Mounts
• docker-compose config – Prüft die Compose-Datei auf Syntaxfehler
• Interaktiver Container-Zugang: docker run -it --entrypoint sh myapp:latest

Präventive Maßnahmen

• Healthchecks definieren: HEALTHCHECK CMD curl -f http://localhost:80 || exit 1
• Exit-Codes überwachen: Restart-Policy setzen (restart: on-failure)
• Ressourcenlimits prüfen, um OOM-Kills zu vermeiden
• Volle Logs analysieren, um wiederkehrende Fehler zu erkennen
• Container-Prozesse möglichst nicht als root ausführen

Beispiel für Compose mit Restart und Healthcheck

version: "3.9"
services:
  web:
    image: myapp:latest
    restart: on-failure
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:80"]
      interval: 10s
      timeout: 5s
      retries: 5
    environment:
      - DB_HOST=db
  db:
    image: mariadb:latest
    environment:
      - MYSQL_ROOT_PASSWORD=secret

Fazit

Container, die mit Exited markiert werden oder in Crashloops geraten, lassen sich systematisch analysieren. Logs, Exit-Codes, Berechtigungen, Umgebungsvariablen, Abhängigkeiten und Ressourcenlimits sind die häufigsten Ursachen. Mit Healthchecks, Restart-Policies und korrekt konfigurierten Compose-Dateien können solche Probleme vermieden und die Stabilität der Multi-Container-Anwendungen erhöht werden.

Konfiguriere Cisco Router & Switches und liefere ein Packet-Tracer-Lab/GNS3

Ich biete professionelle Unterstützung im Bereich Netzwerkkonfiguration und Network Automation für private Anforderungen, Studienprojekte, Lernlabore, kleine Unternehmen sowie technische Projekte. Ich unterstütze Sie bei der Konfiguration von Routern und Switches, der Erstellung praxisnaher Topologien in Cisco Packet Tracer, dem Aufbau und Troubleshooting von GNS3- und EVE-NG-Labs sowie bei der Automatisierung von Netzwerkaufgaben mit Netmiko, Paramiko, NAPALM und Ansible. Kontaktieren Sie mich jetzt – klicken Sie hier.

Meine Leistungen umfassen:

• Professionelle Konfiguration von Routern und Switches

• Einrichtung von VLANs, Trunks, Routing, DHCP, NAT, ACLs und weiteren Netzwerkfunktionen

• Erstellung von Topologien und Simulationen in Cisco Packet Tracer

• Aufbau, Analyse und Fehlerbehebung von Netzwerk-Labs in GNS3 und EVE-NG

• Automatisierung von Netzwerkkonfigurationen mit Python, Netmiko, Paramiko, NAPALM und Ansible

• Erstellung von Skripten für wiederkehrende Netzwerkaufgaben

• Dokumentation der Konfigurationen und Bereitstellung nachvollziehbarer Lösungswege

• Konfigurations-Backups, Optimierung bestehender Setups und technisches Troubleshooting

Benötigen Sie Unterstützung bei Ihrem Netzwerkprojekt, Ihrer Simulation oder Ihrer Network-Automation-Lösung? Kontaktieren Sie mich jetzt – klicken Sie hier.