Errors are a typical aspect of the development and deployment process in the world of Kubernetes container orchestration. The notorious Exit Code 127, which denotes a “file or directory not found” problem inside your containers, is one example of such an error. This blog post will explain Exit Code 127 in detail, look at some of its typical causes, and offer a thorough how-to for diagnosing and resolving this error in Kubernetes deployments.

What is exit code 127?

A standard error message from Unix or Linux-based exit code 127 frequently occurs in the Kubernetes environment. The system uses the exit code as a medium to inform users that a command they want to execute cannot be found.

This is the system’s way of informing  “I attempted to run this, but I was unable to locate the command that you requested.”

Computer systems use exit code 127 to convey the status of a process or command, with zero generally representing success and any non-zero value indicating some sort of error or issue. Exit Code 127, specifically, is part of a range of codes (126 to 165) used to signal specific runtime errors in Linux/Unix-based systems.

Reason for exit code 127 error in Kubernetes

Incorrect Entrypoint or Command in Dockerfile or Pod Specification

One of the most common reasons for Exit Code 127 in Kubernetes is an incorrect entry point or command in the Dockerfile or pod specification. This error occurs when you specify a command or entry point that doesn’t exist or is not executable within the container.

For instance, you might have specified a shell script as your entry point, but the script doesn’t exist at the specified location within the container. Alternatively, the script might exist but is not marked as executable. Both scenarios would lead to Exit Code 127.

Missing Dependencies in the Container

Another frequent cause of Exit Code 127 is missing dependencies within the container. This issue arises when your application or script depends on certain libraries or software that are not available in the container. For example, your application might be written in Python and require certain Python packages to run. If these packages are not installed in the container, the Python interpreter will be unable to find them, resulting in Exit Code 127.

Wrong Image Tag or Corrupt Image

Using an incorrect image tag or a corrupt image can also lead to Exit Code 127. Kubernetes uses Docker images to create containers for your pods. If the image specified in the pod specification is incorrect or corrupt, Kubernetes will be unable to create the container and execute the commands, resulting in Exit Code 127.

Issues with Volume Mounts

Lastly, problems with volume mounts can cause Exit Code 127. In Kubernetes, volumes can be mounted to containers in your pods to provide persistent storage or to share data between containers. If there’s an issue with these mounts, such as a wrong mount path or a permissions problem, it could prevent your application from accessing required files or directories, leading to Exit Code 127.

How to Diagnose Exit Code 127 in Kubernetes 

  1. The following command can be used to examine the pod’s logs to troubleshoot and diagnose the problem: kubectl logs <pod-name>
  2. Additionally, you can view the pod status, which offers comprehensive details about the pod, such as its current status, recent activities, and any error messages.

kubectl describe pod <pod-name>

  • You could also add a container to your pod specifically for debugging purposes that includes a shell (e.g., BusyBox). This allows you to enter the container and manually inspect the environment, paths, and command availability.

Example of using BusyBox for debugging:

containers:

  – name: my-container

    image: my-image:latest

    command: [“/bin/sleep”, “infinity”]

  – name: debug-container

    image: busybox:latest

    command: [“/bin/sh”]

    tty: true

    stdin: true

  • It should be possible for you to determine the root cause of the exit code 127 problem in your Kubernetes pod by closely examining the logs and looking into the previously mentioned aspects. 
  • By addressing the particular issue that the logs have highlighted, you can work toward fixing the underlying issue and guaranteeing that your commands are executed successfully inside the pod.

 

How to fix the exit code 127?

Correct the Entrypoint or Command in Dockerfile or Pod Specification

Changing the entry point or command in your Dockerfile or pod specification is the first step in fixing the issue.  In this step, you will verify that the commands are executable and that the binary path for the application is correctly specified.

For example, if you are using a Dockerfile and your ENTRYPOINT instruction looks like this: ENTRYPOINT [“./app”]

And if ./app isn’t a valid command within your container, you will have to correct it to the right path. It might be that your application binary is in the/app/bin directory and the corrected entry point would look like this: ENTRYPOINT [“/app/bin/app”]

 

Add Missing Dependencies in the Container

Another reason for Exit Code 127 could be that the container’s dependencies are missing. If so, adding the missing dependencies to the container image or pod specification is the fix. 

Suppose your Python application requires the requests library, You would ensure it is installed during image build by adding this to your Dockerfile: RUN pip install requests

Correct the Docker Image Tag or Build a New Image

Making a new image or updating the Docker image tag could be another way to solve the problem. If the image is the issue, the problem might be solved by fixing the image tag. Alternatively, building a new image often helps, especially if the initial image was faulty.

Resolve Volume Mount Issues

If the problem lies in the volumes, resolving mount issues could fix Exit Code 127. This involves ensuring that the volumes are correctly mounted and that they are accessible by the container. This could involve changing the mount path or adjusting the permissions.

Kubernet consulting service with Supportfly

Kubernetes is an open-source container orchestration platform in which SupportFly will help organizations automate the deployment, scaling, and management of containerized applications.

– Kubernetes assessment and planning

– Kubernetes cluster design and deployment

– Application containerization and orchestration

– Kubernetes security and governance

– Kubernetes monitoring and performance optimization

– Continuous integration and delivery (CI/CD) with Kubernetes

Conclusion 

Exit code 127 is a generic error message in Unix and Linux systems that typically indicates “Command not found,” rather than a specific Kubernetes error code. It can be caused by any of the problems listed above in K8 environments. To fix it, locate the error’s cause by reviewing the logs and associated events.