Was der Restart-Loop wirklich aussagt
Mit restart: unless-stopped startet Docker denselben Container erneut, sobald dessen Hauptprozess endet. Die Policy macht einen Fehler sichtbar, sie verursacht ihn nicht.
unhealthy ist ein anderer Zustand. Das itzg-Image prüft Minecraft mit mc-health; eine normale Docker-Restart-Policy startet einen laufenden Container wegen eines fehlgeschlagenen Healthchecks nicht neu. Geschieht es trotzdem, suche nach Autoheal, Portainer-Regeln oder einem Orchestrator.
Schleife stoppen, Beweise behalten
Beginne nicht mit docker compose down, dem Löschen von Volumes oder einem leeren /data. Deaktiviere die Laufzeit-Policy am bestehenden Container und lasse seinen laufenden Fehlstart natürlich enden:
docker compose ps -a
mc_container_id="$(docker compose ps -a -q mc)"
docker update --restart=no "$mc_container_id"
docker wait "$mc_container_id"
docker wait gibt den Exit-Code aus. So überschreibt kein neues Stop-Signal den gesuchten Fehlerzustand. Die Produktions-Policy bleibt in Compose und kehrt bei der Neuerstellung zurück.
Exit-Zustand und ersten Fehler erfassen
docker inspect "$mc_container_id" --format 'exit={{.State.ExitCode}} oom={{.State.OOMKilled}} error={{json .State.Error}} restarts={{.RestartCount}}'
docker compose logs --tail=250 --timestamps mc
Lies den fehlgeschlagenen Start von oben. Die letzten Zeilen enthalten häufig nur Folgefehler beim Herunterfahren.
| Ergebnis | Bedeutung | Nächste Prüfung |
|---|---|---|
| Exit 1 | Initialisierungs- oder Anwendungsfehler | Erste ERROR-, Exception- oder [init]-Zeile |
| Exit 137 | Prozess erhielt SIGKILL | OOMKilled prüfen und Exit-137-Runbook nutzen |
| Exit 143 | Prozess erhielt SIGTERM | Deployment, Bediener oder Stop-Timeout untersuchen |
| Running, aber unhealthy | Prozess läuft, Healthcheck scheitert | Health-Ausgabe und Serverbereitschaft prüfen |
Bei einem laufenden, ungesunden Container:
docker inspect "$mc_container_id" --format '{{json .State.Health}}'
docker compose logs --tail=250 mc
Tatsächliche Compose-Konfiguration prüfen
Oft wurde eine Datei geändert, die Compose gar nicht verwendet:
docker compose config
docker compose images
docker image inspect "$(docker compose images -q mc)" --format '{{json .Config.Labels}}'
Kontrolliere image, TYPE, VERSION, Java-Tag, Volumes und Speicher. docker compose restart übernimmt geänderte Umgebungsvariablen ausdrücklich nicht.
Ersten Fehler einer Ursache zuordnen
| Erste brauchbare Meldung | Wahrscheinliche Ursache | Korrektur |
|---|---|---|
| EULA nicht akzeptiert | EULA fehlt oder ist nicht TRUE | Compose korrigieren und Service neu erstellen |
| Class-Version-/Java-Fehler | Falsches Java-Image | Passenden Java-Tag auswählen |
Permission denied unter /data | Host-Besitz passt nicht zu UID/GID | Berechtigungs-Runbook folgen |
| Keine passende Server-/Pack-Version | TYPE, Version, Projekt oder File-ID falsch | Kompatibles Release fest einstellen |
| Plugin-/Mod-Exception | Inkompatibles oder doppeltes Artefakt | Letzten funktionierenden Satz im Stop-Zustand wiederherstellen |
| Cannot reserve memory | Heap größer als verfügbare Ressourcen | Heap reduzieren oder Kapazität erhöhen |
| Port already allocated | Anderer Prozess belegt Host-Port | Besitzer identifizieren statt blind Port zu wechseln |
Für eine verrauschte Image-Initialisierung vorübergehend:
environment:
DEBUG: "TRUE"
DEBUG_EXEC: "TRUE"
DEBUG_MEMORY: "TRUE" ist für JVM-Speicherprobleme gedacht. Entferne Debug-Flags nach der Analyse.
Korrektur anwenden und verifizieren
docker compose config
docker compose up -d --force-recreate mc
docker compose logs -f mc
docker compose exec mc rcon-cli version
docker compose exec mc rcon-cli save-all flush
docker inspect "$(docker compose ps -q mc)" --format 'restarts={{.RestartCount}} health={{.State.Health.Status}}'
Wiederhole die letzte Prüfung nach einigen Minuten. Der Restart-Zähler darf nicht weiter steigen.
Fehler nicht nur verstecken
- Restart-Policy zu entfernen repariert den Server nicht.
- Lösche
/datanicht vor der Sicherung des Fehlerstands. - Erhöhe keine Timeouts, bevor du den ersten Fehler gelesen hast.
- Deaktiviere den Healthcheck nicht, um fehlende Bereitschaft zu kaschieren.
- Ziehe nicht wiederholt
latestund verändere damit ständig die Fehlerlage.
Nächste Schritte
- Bei Exit 137 mit OOMKilled und Speicherdiagnose fortfahren.
- Für Pack-Fehler das CurseForge-Docker-Runbook verwenden.
- Den stabilen Server anschließend mit der Docker-Sicherheitsbasis härten.