LEARN. PRACTICE. GROW.Concept and mechanism
Diagnosis starts with the correct instance and failure interval. Collect state, effective command, timestamps, and recent changes before replacing the container. docker inspect exposes configuration and state; docker logs depends on log destination and configured driver. Empty output does not establish absence of errors when the application writes to an internal file. Exit code 137 is consistent with SIGKILL termination but does not independently establish memory exhaustion. Correlate it with OOMKilled, events, and metrics from the same interval. If someone forced termination, the explanation may differ from reaching a memory limit. Preserve that distinction in the incident record.
Guided application
In an original exercise, an unconstrained worker competes with other applications. Size memory and CPU from observations and host capacity without assuming isolation creates reserved resources. CPU shares express relative priority under contention rather than a fixed processor reservation. When memory is 512 MiB and memory-swap is 768 MiB, the combined limit leaves up to 256 MiB for swap, depending on support and availability. A restart may restore service without removing the cause; record recurrence and validate processing, connections, and backlog. At handover, include image identity, effective configuration, persistent state, observed signals, and limits of the conclusion. A running process is only part of recovery evidence.
137 plus OOMKilled=true and memory growth supports investigating memory; 137 alone does not close the diagnosis.
Common pitfalls
Exit code as sole cause; empty logs as no error; restart as permanent resolution.
Related topics: Processes and images · Build and distribution · Networking and access
Recover service function and retain enough evidence to explain failure.
Reference: Memory and CPU constraints · Docker Engine Linux containers, BuildKit and Compose; official documentation consulted 2026-09-30; version-dependent behavior explicitly scoped