Der Container-Exit-Code 137 wird oft fälschlich als Out-of-Memory (OOM) interpretiert, was Teams dazu verleitet, Ressourcen vorschnell zu erweitern. In diesem realen Debugging-Fall beendete sich ein Produktionscontainer wiederholt mit Code 137, und die erste Reaktion war, OOM anzunehmen. Ein genauerer Blick auf die Exit-Code-Semantik zeigt jedoch, dass 137 gleich 128 plus Signal 9 (SIGKILL) ist, was durch verschiedene Bedingungen ausgelöst werden kann, einschließlich Host-Neustarts. Der Autor prüfte systematisch die Host-Logs und fand heraus, dass der zugrunde liegende Server unerwartet neu startete, wodurch alle Container getötet wurden. Dieser Fall unterstreicht, wie wichtig es ist, die Linux-Exit-Code-Konventionen zu verstehen und Host-Ereignisse zu prüfen, bevor man voreilige Schlüsse zieht. Für DevOps- und SRE-Teams ist dies eine wertvolle Erinnerung, Container-Exit-Codes mit System-Logs und Metriken zu korrelieren, um verschwendete Arbeit und falsch konfigurierte Infrastruktur zu vermeiden.
Ein Produktionscontainer beendete sich wiederholt mit Code 137, zunächst als OOM fehlinterpretiert. Der Autor zerlegt die Exit-Code-Semantik (128+9=SIGKILL) und entdeckt, dass der Host neu startete, nicht der Container OOM-getötet wurde.