Container exited with code 137
The container was terminated abruptly by the host operating system because it ran out of memory (OOM) or received a SIGKILL signal.
Usually happens because:
- ☑ Container memory consumption hit allocated limits
- ☑ Host system ran out of swap/RAM
- ☑ Process ignored SIGTERM during docker stop
🔍 Quick Checklist:
What is Container exited with code 137?
Exit code 137 indicates that the containerized process was forcefully terminated by a SIGKILL (signal 9) signal. The number 137 is derived from the standard Unix shell convention: 128 (default exit code offset for signal terminations) + 9 (the signal number for SIGKILL). The two most common causes of this termination are: 1) the host kernel's Out-Of-Memory (OOM) Killer terminated the container because the host ran out of physical RAM, or 2) the container failed to stop gracefully within the 10-second grace period during a 'docker stop' command, forcing Docker to send a SIGKILL.
Common Causes
- Out of Memory (OOM) Killer: The host kernel terminated the process because memory consumption exceeded allocated system/container limits.
- Forceful container termination: Running 'docker kill' or running 'docker stop' on a container that ignored the initial SIGTERM signal for more than 10 seconds.
- Docker Desktop resources exhausted: The virtual machine hypervisor running Docker Desktop hit its hard RAM ceiling.
| Cause | Frequency |
|---|---|
| Out of Memory (OOM) termination | ⭐⭐⭐⭐⭐ |
| Forceful docker stop timeout | ⭐⭐⭐⭐ |
| Manual docker kill command | ⭐⭐ |
Common Mistakes
- Assuming exit code 137 always means OOM (it can also mean a manual `docker kill` command or a timed-out `docker stop` command).
- Setting memory limits inside containers too close to the startup overhead requirements of heavy engines (like JVM/Node).
How to Fix
Docker Operations & Verification
Inspect the container state details to verify if it was OOM killed.
$ docker inspect my-container --format '{{.State.OOMKilled}}'
true
# If true, the container was terminated by the OOM killerPlatform Specific Fixes
Inspect Linux kernel messages (dmesg) to confirm OOM terminations.
# Search system logs for Out of Memory events
dmesg -T | grep -i oom
# Or inspect system logs
sudo journalctl -k | grep -i oomBest Practices
- Ensure applications running as PID 1 forward signal requests correctly to child processes (use lightweight entrypoint scripts like `tini`).
- Set up monitoring alerts on container memory utilization metrics.
Frequently Asked Questions (FAQ)
Q: What does exit code 137 mean?
It means the container was forcefully stopped by the host using a SIGKILL (signal 9) signal, usually due to memory exhaustion.
Q: How do I check if my container was OOM killed?
Run 'docker inspect <container_id> --format "{{.State.OOMKilled}}"'. If it prints 'true', it was terminated due to memory limits.
Q: Why does my container ignore docker stop?
If your application process is running as PID 1 and does not forward SIGTERM signals to child processes, it will hang for 10 seconds until Docker kills it with exit code 137.
Q: How do I allocate more memory to a container?
Use the '-m' or '--memory' flag, for example: 'docker run -m 4g my-image'.