Victor's room

Overview & Root Cause Summary: The Docker runtime error standard_init_linux.go:228: exec user process caused: no such file or directory (or exec /entrypoint.sh: no such file or directory) occurs when the container runtime initiates container startup, but fails to execute the specified ENTRYPOINT or CMD binary. In the vast majority of cases, the script itself exists in the container, but contains Windows CRLF (\r\n) line endings causing the Linux kernel to search for a non-existent interpreter (e.g. /bin/sh\r), points to an invalid shebang path, lacks execution permissions, or is a dynamically linked binary compiled against glibc trying to run inside a musl-based Alpine container.

Understanding the Root Causes

• Windows CRLF Carriage Return Characters: Scripts created or checked out via Git on Windows machines save lines with carriage returns (\r\n). The Linux kernel interprets the first line as #!/bin/sh\r, attempting to execute the literal file /bin/sh\r which does not exist.
• Alpine Linux vs glibc Dynamic Linker Mismatch: Go, C++, or Rust binaries dynamically linked against GNU C Library (glibc) on Ubuntu/Debian cannot resolve the dynamic linker (/lib64/ld-linux-x86-64.so.2) when placed inside minimal Alpine Linux images (which use musl libc).
• Incorrect or Missing Shebang: The entrypoint script lacks a shebang declaration (#!/bin/sh) or specifies a missing interpreter (e.g., #!/bin/bash in Alpine where only /bin/sh is installed).
• Missing File Execution Permission: The script was copied into the container without the executable mode bit (chmod +x).

Step 1: Convert Windows CRLF Line Endings to Unix LF

Strip carriage return characters from your entrypoint script on your host machine and enforce LF endings in Git.

# 1. Convert carriage returns using dos2unix:
dos2unix entrypoint.sh

# Or using sed on Linux/macOS:
sed -i -e 's/\r$//' entrypoint.sh

# 2. Inspect the file format to ensure it uses Unix LF:
file entrypoint.sh
# Expected output: POSIX shell script, ASCII text executable (no "CRLF line terminators")

# 3. Prevent Git on Windows from converting LF to CRLF by adding a .gitattributes file:
# In your repository root:
echo "* text=auto eol=lf" >> .gitattributes
echo "*.sh text eol=lf" >> .gitattributes

Step 2: Validate Shebang Line and Executable Permissions

Ensure the interpreter path is supported by the base image and the script has executable permissions.

# 1. Open entrypoint.sh and verify the first line:
# For universal compatibility (including Alpine and Ubuntu):
#!/bin/sh
set -e

# Or if using Bash features:
#!/usr/bin/env bash
set -e

# 2. Grant executable permission on the host:
chmod +x entrypoint.sh

# 3. Or enforce execution permissions inside your Dockerfile:
COPY entrypoint.sh /entrypoint.sh
RUN chmod +x /entrypoint.sh
ENTRYPOINT ["/entrypoint.sh"]

Step 3: Fix Missing glibc Dynamic Linker in Alpine Containers

If running pre-compiled binary executables inside Alpine Linux, install glibc compatibility libraries or compile statically.

# Option A: Install glibc compatibility package in Alpine Dockerfile:
RUN apk add --no-cache libc6-compat gcompat

# Option B: For Go binaries, build a fully static binary without CGO:
CGO_ENABLED=0 GOOS=linux go build -a -installsuffix cgo -o myapp .

# Option C: Check dynamic library requirements of the binary on Linux:
ldd myapp
# If output shows "not a dynamic executable", the binary is fully static and safe for Scratch/Alpine.

Verification & Testing Steps

Verify line endings, test execution locally, and confirm container initialization.

# 1. Verify line endings using cat -v (should NOT show ^M at end of lines):
cat -v entrypoint.sh | head -n 5

# 2. Rebuild the Docker image without cache:
docker build --no-cache -t test-app:latest .

# 3. Test launch container:
docker run --rm test-app:latest

# 4. Check exit code (should return 0):
echo $?

Summary Comparison Table