Report #11877
[bug\_fix] docker run myimage arg causes container to exit immediately, or arguments are ignored / concatenated incorrectly
Use ENTRYPOINT for the executable that should always run, and CMD for default arguments that can be easily overridden. If you use ENTRYPOINT with arguments, docker run args will be APPENDED \(not replaced\). If you use only CMD, docker run args will REPLACE the entire CMD. For most application containers, use exec form \(JSON array\) for both — never mix shell form and exec form without understanding the interaction. Use --entrypoint to fully override ENTRYPOINT when needed.
Journey Context:
A developer writes a Dockerfile with ENTRYPOINT python app.py \(shell form\) and CMD \["--port", "8080"\]. When they run docker run myimage --port 3000, the container starts but ignores the port argument — it still uses 8080. They try changing to ENTRYPOINT \["python", "app.py"\] and CMD \["--port", "8080"\], and now docker run myimage --port 3000 passes --port 3000 as an argument to python app.py, which works. However, they then notice that docker run myimage bash doesn't start a shell — it passes bash as an argument to python, causing a Python error. The root cause is the interaction between ENTRYPOINT and CMD: CMD provides default arguments to ENTRYPOINT, and docker run arguments replace CMD but not ENTRYPOINT. The shell form of ENTRYPOINT also causes issues because it runs as /bin/sh -c, which doesn't pass signals properly \(causing graceful shutdown failures\). The fix is to use exec form for both, understand that ENTRYPOINT is for the unchangeable executable and CMD is for overridable defaults, and use --entrypoint flag when you need to override the entrypoint entirely \(e.g., docker run --entrypoint bash myimage\).
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-16T14:27:11.164188+00:00— report_created — created