Komodor is a Kubernetes management platform that empowers everyone from Platform engineers to Developers to stop firefighting, simplify operations and proactively improve the health of their workloads and infrastructure.
Proactively detect & remediate issues in your clusters & workloads.
Easily operate & manage K8s clusters at scale.
Reduce costs without compromising on performance.
Empower developers with self-service K8s troubleshooting.
Simplify and accelerate K8s migration for everyone.
Fix things fast with AI-powered root cause analysis.
Explore our K8s guides, e-books and webinars.
Learn about K8s trends & best practices from our experts.
Listen to K8s adoption stories from seasoned industry veterans.
The missing UI for Helm – a simplified way of working with Helm.
Visualize Crossplane resources and speed up troubleshooting.
Validate, clean & secure your K8s YAMLs.
Navigate the community-driven K8s ecosystem map.
Kubernetes 101: A comprehensive guide
Expert tips for debugging Kubernetes
Tools and best practices
Kubernetes monitoring best practices
Understand Kubernetes & Container exit codes in simple terms
Exploring the building blocks of Kubernetes
Cost factors, challenges and solutions
Kubectl commands at your fingertips
Understanding K8s versions & getting the latest version
Rancher overview, tutorial and alternatives
Kubernetes management tools: Lens vs alternatives
Troubleshooting and fixing 5xx server errors
Solving common Git errors and issues
Who we are, and our promise for the future of K8s.
Have a question for us? Write us.
Come aboard the K8s ship – we’re hiring!
Hear’s what they’re saying about Komodor in the news.
Exit Code 1 indicates that a container shut down, either because of an application failure or because the image pointed to an invalid file. In a Unix/Linux operating system, when an application terminates with Exit Code 1, the operating system ends the process using Signal 7, known as SIGHUP.
In Kubernetes, container exit codes can help you diagnose issues with pods. If a pod is unhealthy or frequently shuts down, you can diagnose the problem using the command kubectl describe pod [POD_NAME]
kubectl describe pod [POD_NAME]
If you see containers terminated with Exit Code 1, you’ll need to investigate the container and its applications more closely to see what caused the failure. We’ll provide several techniques for diagnosing and debugging Exit Code 1 in containers.
This is part of a series of articles about Exit Codes.
Exit Code 1 means that a container terminated, typically due to an application error or an invalid reference.
An application error is a programming error in any code running within the container. For example, if a Java library is running within the container, and the library throws a compiler error, the container might terminate with Exit Code 1.
An invalid reference is a file reference in the image used to run the container, which points to a nonexistent file.
In Unix or Linux operating systems, signals help manage the process lifecycle. When a container terminates with Exit Code 1, the operating system terminates the container’s process with Signal 7.
Signal 7 is also known as SIGHUP – a term that originates from POSIX-compliant terminals. In old terminals based on the RS-232 protocol, SIGHUP was a “hang up” indicating the terminal has shut down.
To send Signal 7 (SIGHUP) to a Linux process use the following command:
kill - HUB [processID]
Itiel Shwartz
Co-Founder & CTO
In my experience, here are tips that can help you better handle “Container Terminated with Exit Code 1”:
Ensure all necessary environment variables are correctly set and accessible.
Use log aggregation tools to simplify the log analysis process.
Ensure all application dependencies are installed and compatible.
Use tools like Prometheus to monitor CPU, memory, and disk usage for early detection of issues.
Employ APM tools to pinpoint application-level issues causing exits.
When a container exits, the container engine’s command-line interface (CLI) displays a line like this. The number in the brackets is the Exit Code.
Exited (1)
To list all containers that exited with an error code or didn’t start correctly:If you are using Docker, run ps -la
ps -la
To diagnose why your container exited, look at the container engine logs:
If you are running containers as part of a Kubernetes cluster, you can find the exit code by gathering information about a pod.
Run the kubectl describe pod [POD_NAME] command.
The result will look something like this:
Containers: kubedns: Container ID: ... Image: ... ... State: Running Started: Fri, 15 Oct 2021 12:06:01 +0800 Last State: Terminated Reason: Error Exit Code: 1 Started: Mon, 8 Nov 2021 22:21:42 +0800 Finished: Mon, 8 Nov 2021 23:07:17 +0800 Ready: True Restart Count: 1
It is a good idea to start your troubleshooting by recreating the container. This can clean out temporary files or other transient conditions that may be causing the error. Deleting and recreating will run the container with a fresh file system.
To delete and recreate the container:
kubectl delete pod [pod-name]
kubectl run [pod-name] --image=[image-name]
2. Bashing Into a Container To Troubleshoot ApplicationsIf your container does not use entrypoints, and you suspect Exit Code 1 is caused by an application problem, you can bash into the container and try to identify which application is causing it to exit.
To bash into the container and troubleshoot applications:
docker run -ti --rm ${image} /bin/bash
Note: Another way to troubleshoot an application is to simply run the application, with the same command line, outside the container. For this to be effective, you need to have an environment similar to that inside the container on the local machine.
Exit Code 1 is often caused by application errors that cause the application, and the entire container, to exit. If you determine that Exit Code 1 is caused by an application, you can experiment with various configuration options of the application to prevent it from exiting.
Here is a partial list of application parameters you can try:
Some Exit 1 errors are caused by the PID 1 problem. In Linux, PID 1 is the “init process” that spawns other processes and sends signals.
Ordinarily, the container runs as PID 2, immediately under the init process, and additional applications running on the containers run as PID 3, 4, etc. If the application running on the container runs as PID 2, and the container itself as PID 3, the container may not terminate correctly.
To identify if you have a PID 1 problem
docker ps -a
ps -aux
PID USER PR NI VIRT RES %CPU %MEM TIME+ S COMMAND1 root 20 0 1.7m 1.2m 2.0 0.5 0:05.04 S {command used to run your application}
Possible solutions for the PID 1 problem
tini
dumb-init
docker-compose
docker-compose.yml
These four techniques are only some of the possible approaches to troubleshooting and solving the Exit Code 1 error. There are many possible causes of Exit Code 1 which are beyond our scope, and additional approaches to resolving the problem.
As a Kubernetes administrator or user, pods or containers terminating unexpectedly can be a pain and can result in severe production issues.
Exit Code 1 is a prime example of how difficult it can be to identify a specific root cause in Kubernetes because many different problems can cause the same error. The troubleshooting process in Kubernetes is complex and, without the right tools, can be stressful, ineffective, and time-consuming.
Komodor is a Kubernetes troubleshooting platform that turns hours of guesswork into actionable answers in just a few clicks. Using Komodor, you can monitor, alert and troubleshoot exit code 1 event.
exit code 1
For each K8s resource, Komodor automatically constructs a coherent view, including the relevant deploys, config changes, dependencies, metrics, and past incidents. Komodor seamlessly integrates and utilizes data from cloud providers, source controls, CI/CD pipelines, monitoring tools, and incident response platforms.
Share:
and start using Komodor in seconds!