Docker ENTRYPOINT vs CMD: Exec Form, Shell Form, and PID 1 Behavior

How ENTRYPOINT and CMD combine

The final command Docker executes is the concatenation of ENTRYPOINT + CMD:

| Dockerfile | docker run command | Executed as | |---|---|---| | ENTRYPOINT ["/app"] | docker run img | /app | | ENTRYPOINT ["/app"] + CMD ["--port", "8080"] | docker run img | /app --port 8080 | | ENTRYPOINT ["/app"] + CMD ["--port", "8080"] | docker run img --port 9090 | /app --port 9090 | | No ENTRYPOINT + CMD ["node", "server.js"] | docker run img | node server.js |

CMD is the default argument list. Arguments passed to docker run after the image name replace CMD entirely. ENTRYPOINT is harder to override — it requires --entrypoint.

Exec form vs shell form

Both ENTRYPOINT and CMD support two syntaxes with different PID 1 behavior:

# Exec form — recommended
# Process runs directly as PID 1, receives signals
ENTRYPOINT ["node", "server.js"]

# Shell form — wraps in /bin/sh -c
# Actual executed command: /bin/sh -c "node server.js"
# node is a child of sh (PID 2+), not PID 1
ENTRYPOINT node server.js

Entrypoint scripts for flexible containers

A shell entrypoint script is useful when you need to run initialization before the main process (wait for database, inject secrets, set up config files):

FROM python:3.11-slim

COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

COPY entrypoint.sh /entrypoint.sh
RUN chmod +x /entrypoint.sh

COPY . /app
WORKDIR /app

ENTRYPOINT ["/entrypoint.sh"]   # exec form
CMD ["python", "server.py"]     # default arguments, overridable

#!/bin/sh
set -e

# Run initialization
echo "Waiting for database..."
until nc -z "$DB_HOST" 5432; do
  sleep 1
done

# The key pattern: exec replaces the shell process with the application
# This makes the application PID 1 (inheriting signals correctly)
exec "$@"

The exec "$@" at the end replaces the shell with the CMD arguments (e.g., python server.py). Without exec, the shell remains PID 1 and the application is a child — back to the signal handling problem.

# Flexible container: override the default command
docker run myapp python manage.py migrate   # runs migration instead
docker run myapp python -m pytest          # runs tests instead
# Both cases: entrypoint.sh runs first, then exec "$@" runs the given command

docker exec vs container startup

docker exec bypasses ENTRYPOINT and CMD entirely — it runs a command directly in the running container's namespace:

# ENTRYPOINT and CMD are irrelevant to docker exec
docker exec -it my-container bash
docker exec my-container ls /app
docker exec my-container python manage.py shell

docker exec is useful for debugging a running container without restarting it. The executed command runs as a separate process in the container — it doesn't replace PID 1.

# Override entrypoint to run a shell instead
docker run --entrypoint /bin/bash -it myapp

# Run a one-off command with a different entrypoint
docker run --entrypoint python myapp -c "import sys; print(sys.version)"

# In docker-compose.yml
services:
  debug:
    image: myapp
    entrypoint: /bin/sh
    command: ["-c", "while true; do sleep 1; done"]