Estimated reading time: 11 minutes
Last updated on November 9th, 2024 at 01:31 pm
Docker Container Exit Code 137 means a container was terminated due to Out of Memory (OOM) issues or received a kill signal. It typically occurs when the container runs out of allocated memory or is manually stopped.
Table of Contents
What Does Docker Exit Code 137 Mean?
While working with Docker, sometimes the container crashes with an error code. This error message helps you investigate why the Docker Container exited.
When you see exit code 137, a signal from Docker that something unexpected happened, your Docker Container needs to shut down forcefully instead of gracefully.
Docker sends the SIGKILL message to the container and stops it immediately. This forceful and sudden container exit leads to Docker container exit code 137.
Exit code 137 isn’t ideal and we don’t know what happened with Docker.
Let’s check what causes the exit code 137, troubleshooting steps, and prevention to make your container run smoothly again.
Common Causes of Docker Container Exit Code 137
Due to unexpected reasons, Docker forcefully shut down the container with exit code 137. Now let’s check the three main reasons why Docker container crashes behind this:
1. Out-of-Memory (OOM) Conditions
When a Host machine runs out of memory (RAM) to handle all the tasks, it can lead to unexpected problems. Performing the OS level important task is crucial hence it starts killing the processes to free up the memory.
Docker can adjust priority for OOM priority to reduce the risk of being killed, but for individual containers, it can be killed and crash with exit code 137.
You should also check the default memory limit in the Docker to safeguard from OOM exceptions and better Docker memory management.
2. External Termination (SIGKILL Signal)
When you run the docker stop
the container will stop but sometimes the Docker container becomes unresponsive and behaves unexpectedly.
To stop this frozen container you need to use docker kill
command that sends the SIGKILL
signal to the container. SIGKILL
is a special “kill switch” signal for the container that kills the process forcefully.
If your Docker becomes unresponsive and the docker kill
command stops working, check this advanced troubleshooting guide on Docker Kill Command Not Working
There are a few ways this SIGKILL
is sent, leading to exit code 137:
- Docker commands: If you use
docker kill
command it can forcefully stop a container, resultingSIGKILL
and exit code 137. - Kubernetes: If you’re using Kubernetes to manage containers, it might send a
SIGKILL
signal to terminate an unresponsive container leading to exit code 137. - User-initiated: If you run
kill -9
, this can forcefully terminate the process, including the Docker container. It sendsSIGKILL
a signal, causing exit code 137.
3. Application Errors or Bugs
When the Docker container starts it runs the application as the main process with PID
1 and keep running until the main process finishes.
The application running inside your Docker container might have errors or bugs. Due to that, it might cause the Docker container to crash unexpectedly throwing the error Docker container exit code 137.
It’s important to monitor your Docker container logs to ensure it’s running smoothly. If you want your container to keep running for debugging check out the guide on 6 Best Ways to Keep Docker Container Running For Debugging.
Rare Causes of Docker Container Exit Code 137
If you think that the above-mentioned common cause is not the case, you can check the below rare cause of Docker Container Exit Code 137
1. Kernel Memory Allocation Failures
In rare cases, the Docker container might be terminated with exit code 137 due to the issue with the Operating System kernel that allocates memory to the container.
If the Operating System kernel can’t allocate additional memory, it may send a signal to kill containers running resource-intensive applications.
You can check the kernel message with the below 3 methods:
dmesg -w
# System with systemd
journalctl --system -f
tail -F /var/log/messages
2. Swap Usage Configuration:
You may have incorrect swap usage or a limit on Docker swap usage.
if the swap memory is exhausted or limited, the process may need to go back to system memory and get terminated by the system.
You can check the swap usage with the following command:
cat /proc/swaps
3. Underlying Storage or Network I/O Delays
Docker containers are dependent on I/O and if your application is a database or high-throughput application it needs high I/O.
One rare reason can be the I/O, if the wait becomes too high it can get killed. OS might consider that as a potential consumption of excessive system resources and killed it.
4. CPU Limit Misconfiguration
Misconfiguring Docker CPU limits or pinning can lead to unexpected behavior. The system may kill processes that exceed their assigned CPU quota over time.
Step-by-Step Guide to Fixing Docker Container Exit Code 137
1. Check for OOM Conditions
If you encounter a memory shortage with an OOM exception, here’s how to investigate:
Docker Inspect:
docker inspect
can provide comprehensive details about your container. You can check if an OOM situation caused the Docker container exit code 137 with the following command:
docker inspect <container_name>
Look for the “OOMKilled” value if it’s true
then memory shortage is likely the cause here.
Docker Stats:
docker stats
command shows the real-time resource utilization of your running Docker containers. Optimize container resources look for high memory usage, especially for the container with exit code 137.
docker stats
CONTAINER ID NAME CPU % MEM USAGE / LIMIT MEM % NET I/O BLOCK I/O PIDS
12ab34cd56ef nginx_container 0.5% 50MiB / 512MiB 10% 1.2MB / 0.3MB 100kB / 20kB 5
ab34cd56ef78 python_app 12.3% 850MiB / 1024MiB 85% 3.5MB / 2.1MB 300kB / 150kB 10
In this example, the python_app
the container utilizes 85% of memory.
System Monitoring Tools:
All major operating systems have built-in tools for monitoring memory usage. Use these tools to see the host machine’s memory usage.
If you work on Linux you can use htop
or top
command, for Windows users you can use Task Manager
and for Mac users, you can use Activity Monitor
.
Container Logs:
Lastly, check for the container logs, they might have messages about the resource limitation and clues about memory-related issues.
If you don’t know how to check the Docker containers logs, check out this guide on Docker Container Logs Location: A Comprehensive Guide
2. Identify External Termination
If you think that memory shortage is not the root cause, let’s check if something forcefully stopped the container:
Command History:
You can check your recent commands or BASH
history to see if you find the docker kill
or kill -9
commands that run accidentally.
history
ls
git satus
docker ps
docker ps -a
docker stop nginx_proxy
docker kill nginx_proxy ## docker kill can cause Docker container exit code 137
htop
Kubernetes Logs:
If you’re using the Kuberetent to manage and run the Docker containers, check the logs for any related events that cause the container termination.
Inspecting the logs and events in detail can reveal why Kubernetes sent the SIGKILL
signal.
3. Debug Application Errors
if the first two steps didn’t solve why the Docker container exit code 137, the application issue might be the real culprit.
Use tools like Prometheus, cAdvisor, or Docker Stats to monitor memory usage. Detecting spikes can help identify potential memory leaks.
Check out the additional debugging tutorials:
- 6 Best Ways to Keep Docker Container Running For Debugging
- How to Attach and Detach From a Docker Container
- Docker Kill Command Not Working: Troubleshooting Guide
- Enter Docker Container Shell – 4 Effective Methods
- Docker Container Logs Location: A Comprehensive Guide
By following these troubleshooting steps, you will be on your way to finding the cause of exit code 137 and getting your Docker container up and running.

FREE EBook – Docker Defence Unbeatable Security
Are you leveraging Docker’s potential, but worried about security vulnerabilities? Our ebook, “Docker Defence: Unbeatable Security“, is your key to mastering container security. Packed with actionable checklists and expert tips, you’ll discover:
Don’t wait! Download your free copy and unlock the full potential of Docker!
Best Practices for Avoiding Docker Container Exit Code 137
Now that you’ve checked the troubleshooting exit code 137, let’s explore the best practice to prevent it from happening again.
1. Setting Resource Limits to Prevent Docker Container Exit Code 137
Memory Limit:
When you run the Docker container use the --memroy
or -m
flag to specify the memory limit for your container. This prevents memory shortage issues on the host machine and Docker.
Kubernetes Request/Limits:
In Kubernetes, you can configure the resource request and limit for your containers. This prevents resource constraints and conflict within Kubernetes.
Monitoring/Scaling:
Keep an eye on your container resource utilization with docker stats
command. If containers utilize high memory consistently, consider calling and allocating more resources.
2. Avoid External Termination to Prevent Docker Container Exit Code 137
You can stop the running Docker container gracefully instead of forcefully:
docker stop
:
Use the docker stop
instead of docker kill
this sends the SIGTERM
signal instead of SIGKILL
, allow the application to clean up and exit gracefully.
Kubernetes:
Follow the best practices for managing the container lifecycle with Kubernetes. Commands like kuberctl delete
can be used for termination and scaling.
3. Handle Application Errors to Prevent Docker Container Exit Code 137
The application can have bugs and encounter errors, but you can make them resilient:
Error Handling:
Implement proper error handling in your application to throw and cache various exceptions with the specific error message instead of panicking and crashing the application unexpectedly.
Health Checks:
Set up the health check for your containers. Health check can keep checking the application’s health and send an alert if something is wrong with the container.
Quick Reference: Causes, Symptoms, and Fixes for Docker Container Exit Code 137
Cause | Symptoms | Fixes |
---|---|---|
Out of Memory (OOM) | Container stops with Exit Code 137 | Increase memory allocation or set --memory limits |
Excessive Application Load | High memory usage and frequent crashes | Optimize code, reduce workload, or scale containers |
External Kill Signals (SIGKILL) | Unexpected termination by system or admin | Check for external processes sending kill commands |
Incorrect Docker Settings | Inconsistent performance or errors | Review Docker configurations and container parameters |
FAQs:
What is Docker Container Exit Code 137?
Exit Code 137 indicates that a Docker container was terminated due to an Out of Memory (OOM) event or because it was killed manually with a kill -9
command.
Why is my Docker container running out of memory?
Your container might be running out of memory limits due to high resource consumption by applications inside the container. Configuring appropriate memory limits can help mitigate this issue.
How can I troubleshoot Docker Exit Code 137?
You can check the container logs docker logs <container_id>
and inspect the container using docker inspect <container_id>
to understand if memory was the issue.
Can Docker Exit Code 137 occur without an OOM event?
Yes, Exit Code 137 can occur due to other factors like manual termination (kill -9
), system-level issues, or improper shutdowns, even when memory isn’t the root cause.
How can I prevent Docker Exit Code 137 in the future?
You can set memory limits using the --memory
and --memory-swap
flags and monitor container resource usage.
What are common applications that trigger Exit Code 137?
Applications like Java, huge databases, and machine learning (ML) workloads are known to frequently hit memory limits and trigger Exit Code 137.
What is the difference between Exit Code 137 and other exit codes like 1 or 143?
Exit Code 137 usually signifies an OOMKill, while Exit Code 1 is a general error, and 143 means a container terminated by a SIGTERM
signal.
Conclusion:
Key Takeaways:
- Docker container exit code 137 is irregular behavior caused by unexpected termination due to
SIGKILL
- Two main reasons for exit code 137:
- Resource Limitation: The container ran out of memory (OOM) on the host machine.
- External Termination: The container was forcefully terminated with
SIGKILL
- Less frequent reasons include application-side bugs and errors.
- Troubleshoot the issue, check with
docker inspect
,docker stats
, check the external terminal event, or container logs - Prevent this in the future:
- Optimize the resource allocation
- Avoid commands that send unintended
SIGKILL
signal - Proper error and exception handling in the application
Understanding these key takeaways can help you to identify the root cause, effectively troubleshoot, and prevent the error Docker container exit code 137.