How to avoid Docker containers failing with error 137

The most common question we get from users is “Why is my container not running?”

The first reply to this issue is to check exit code 137 for the docker container. The exit code can provide information about why the container is shutting down.

Now, what does exit code 137 in Docker mean? The exit code 137 in Docker is an error indicating that the container was killed by an OOM (out of memory) killer. And this happened because Docker does not have enough memory in the container to run the process and finish the work. Unfortunately, Docker uses lots of memory. So, the container will crash due to lack of sufficient memory and show an exit code 137 error.

In this article, we will understand “what is the main cause of the “exit code 137” error message and “how to fix it effectively.” 

How-to-avoid-Docker-containers-failing-with-error-137

Reasons for error 137 in Docker

When you are listing the container using the code command “docker ps-a”, the Docker will strike and show a message “Exited” in the container “STATUS”.

The exit code 137 will also indicate OOM-killer, which means the container was killed because it used more memory than is allowed to. In the host machine, the container has fixed or limited resources to optimize. A container can be specified by a memory limit, which means the maximum amount of memory a container is allowed to use, and a memory request, which means the minimum amount of memory the container is expected to use. If a container uses more than the allocated amount of memory, this error occurs with an OOMKilled status because there is no longer adequate memory available in the container that is used to run the process.

Now, let’s move on to know how to debug the exit code 137 in Docker.

Eliminating error 137 in Docker

It is now clear that the trigger with error code 137 occurs when the OOM-killer is in the

process of freeing up some memory in the system. But how to avoid this error?

To begin, each Docker container is associated with a log file. These log files store all the relevant data, information, and updates related to the container.

So, if the container crashes due to error code 137, inspecting the container log files is an important option for learning about troubleshooting. It is easy to inspect details about the crash by checking container log files. For this purpose, use “docker log” as recommended. This will help you to know that the container was killed due to the process of taking too much memory.

Let’s dive deep to know more about the causes of OOM-error 137 in docker containers.

What causes ‘Out of memory’ error 137 in Docker?

If we see a docker system architecture, the docker container is an application hosted by the docker engine on the host machine. Exit code 137 usually occurs due to two main reasons. For the reasons stated below:

  •  Docker container is short of memory. 

By default, the Docker container uses the memory available on the host machine. There are two docker containers available in the docker system. To save a single container from any abuse by the host resources, it is necessary to set a memory limit per container. But if the container’s use of memory exceeds the imit set for the container, the OOM-killer terminates the application, and the container crashes. An application can only use up too much memory in some cases like if it has a bad configuration setting, the service is not optimized, there is high traffic, or the resource is abused by the user.

  • Docker host machine has no free memory

Every Docker container has been allotted a limited amount of memory based on the total available memory on the host machine. When usage or traffic increases, the available memory may become insufficient to run the process for all containers in the host machine. As a result, the docker container crashed and comes with an error code 137.

Step forward to knowing how  to resolve error 137 in a Docker container.

Ways to Resolve error 137 in Docker

When a Docker container suffers from a lack of memory, the error code 137 shows up on the screen. We discovered two major reasons for exit code 137 error. After examining the causes, the following actions can be taken to avoid or resolve error 137 in the docker container. So let’s understand them closely. 

  •  Optimizing the services

An unoptimized application may use more memory than is necessary. Suppose a MySQL server is misconfigured, it can quickly use up all of the host memory. Therefore, monitoring the application that is operating in the container and service optimization come first. Editing the configuration file or recompiling the service are two options for doing this.

  •  Mounting config files from outside the container

 Mounting configuration files for services located somewhere other than a Docker container is always a good idea. As a result, editing them will be simple without having to rebuild the Docker image. For instance, “/etc/MySQL/conf.d” can be mounted as a volume in the MySQL docker image. Any modifications to the MySQL service’s configuration can be made without changing that image.

  • Monitoring container usage

 The memory utilization of the container must be closely monitored to identify abusive users, resource-hungry programs, traffic peaks, etc. Memory restrictions for the containers can be altered to better serve their business needs based on the volume of traffic and resource utilization of the processes.

  •  Adding more memory to the host machine

 If the containers are using all of their available memory after optimizing the services and setting memory restrictions, additional RAM needs to be added. When there is a memory crunch, adding more RAM and making sure the host computer has enough swap memory will enable the containers to use that memory.

Conclusion

Today, we learned how to use a methodical debugging approach to resolve Docker problem 137. However, there may be circumstances in which the error code is not shown, particularly if the container is launched from a shell script.

 Never allow container crashes to hurt your business! Hire MyAdmin specialists can look after your infrastructure and quickly fix any container problems. We’d be pleased to speak with you if you’d like to learn how to efficiently manage your Docker resources for your company’s needs.