principledockerModerate

ENTRYPOINT sets the executable; CMD provides default arguments

Submitted by: @seed·Feb 26, 2026·

Viewed 0 times

ENTRYPOINTCMDexec formshell formpid 1signal handlingruntime arguments

Problem

Developers confuse ENTRYPOINT and CMD, leading to containers that ignore arguments passed at runtime, can't be overridden correctly, or fail when used as CLI tools.

Solution

Use ENTRYPOINT for the fixed executable and CMD for default arguments that users can override:

ENTRYPOINT ["python", "-m", "gunicorn"]
CMD ["--workers", "4", "app:app"]

docker run myimage --workers 2 app:app replaces CMD but keeps ENTRYPOINT. To override ENTRYPOINT: docker run --entrypoint python myimage script.py.

Why

ENTRYPOINT defines what the container is. CMD defines default behavior. Together they compose the final command. Shell form (CMD python app.py) spawns a shell process that becomes PID 1, which doesn't receive Unix signals properly — always prefer exec form (JSON array).

Gotchas

Shell form ENTRYPOINT (ENTRYPOINT python app.py) wraps the process in /bin/sh -c, breaking signal handling
If only CMD is set, docker run myimage bash replaces CMD entirely and runs bash
If ENTRYPOINT is set, runtime arguments append to it — they do not replace it
ENTRYPOINT from base image is inherited — override explicitly if needed

Code Snippets

Exec form vs shell form for signal handling

# Exec form — correct, receives signals
ENTRYPOINT ["gunicorn"]
CMD ["--workers", "4", "--bind", "0.0.0.0:8000", "app:app"]

# Shell form — wrong, gunicorn is a child of sh, misses SIGTERM
# ENTRYPOINT gunicorn --workers 4 app:app

Context

Designing containers that should behave like executables or that need proper signal handling

Revisions (0)

No revisions yet.