Docker ENTRYPOINT Script Execution Failure: Standard Init Error Analysis and Solutions

Problem Phenomenon and Background

During Docker container deployment, developers frequently encounter errors where ENTRYPOINT scripts fail to execute. The specific manifestation is the container throwing standard_init_linux.go:175: exec user process caused "no such file or directory" error message upon startup. This error typically occurs when using custom entrypoint scripts, even when the script files are correctly copied into the container and execution permissions are properly set.

In-depth Error Cause Analysis

Through thorough analysis of the failure case, the core issue lies in the environment configuration of the base image. In the provided example, vault:latest is used as the base image. This image is built on Alpine Linux or other lightweight distributions, and to maintain small image sizes, it typically does not include a complete Bash shell environment.

When ENTRYPOINT is set to ["/docker-entrypoint.sh"], Docker directly executes the script file. However, the shebang line #!/bin/bash at the beginning of the script specifies using /bin/bash as the interpreter. If the base image does not contain the /bin/bash executable file, the system cannot locate the specified interpreter, resulting in the "no such file or directory" error.

Solution Comparison

Solution 1: Modify shebang to /bin/sh

Changing the script's shebang line from #!/bin/bash to #!/bin/sh is the most direct solution. In most Linux distributions, /bin/sh is a symbolic link to the standard shell, typically pointing to dash or Bash compatibility mode. Lightweight images like Alpine Linux all include /bin/sh, ensuring script execution capability.

#!/bin/sh
echo 'Hello World!'

Solution 2: Remove shebang line

In some cases, the shebang line can be removed entirely. When ENTRYPOINT uses the exec form (JSON array format), Docker executes the script directly as an executable file. If the script content is simple and doesn't rely on specific shell features, the system will use the default shell interpreter for execution.

echo 'Hello World!'

Cross-platform Compatibility Considerations

Beyond the missing interpreter issue in base images, line ending problems in Windows environments are common pitfalls. Git on Windows systems by default converts Unix-style LF line endings to Windows-style CRLF, which changes the shebang line to #!/bin/bash\r, similarly causing "no such file or directory" errors.

Resolution methods include:

• Configure Git to use LF line endings: git config --global core.autocrlf input
• Add .gitattributes file to the project, specifying *.sh text eol=lf
• Use text editors to ensure script files are saved in Unix format

Best Practice Recommendations

To ensure reliable execution of Docker ENTRYPOINT scripts, follow these best practices:

1. Understand Base Image Environment: Before using any base image, understand its included shell environment and available tools.
2. Use /bin/sh as Default Shebang: Unless Bash-specific features are truly needed, use #!/bin/sh to ensure maximum compatibility.
3. Verify Script Executability: Test script syntax and functionality locally before building the image.
4. Handle Line Ending Issues: Use LF line endings uniformly in cross-platform development environments.
5. Use Multi-stage Builds: Consider preparing execution environments in multi-stage builds for complex scripts.

Technical Principles Deep Dive

Docker's ENTRYPOINT mechanism, during container startup, invokes the Linux system's execve system call. When using script files as entry points, the system reads the script's shebang line to determine the interpreter to use. If the specified interpreter doesn't exist, the execve call fails, returning ENOENT (No such file or directory) error.

This design embodies Docker's lightweight philosophy: each image contains only necessary components, avoiding unnecessary dependencies. Developers need to explicitly understand what runtime environments their chosen base images provide, rather than assuming all Linux environments are identical.