-
Notifications
You must be signed in to change notification settings - Fork 1.5k
docs: clarify that ENTRYPOINT discards an inherited CMD #7009
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change | ||||||
|---|---|---|---|---|---|---|---|---|
|
|
@@ -2129,6 +2129,10 @@ executable doesn't receive a `SIGTERM` from `docker stop <container>`. | |||||||
|
|
||||||||
| Only the last `ENTRYPOINT` instruction in the Dockerfile will have an effect. | ||||||||
|
|
||||||||
| Setting `ENTRYPOINT` also discards any `CMD` inherited from the base image, | ||||||||
| unless the same build stage defines its own `CMD`. For more information, see | ||||||||
| [Understand how CMD and ENTRYPOINT interact](#understand-how-cmd-and-entrypoint-interact). | ||||||||
|
|
||||||||
| ### Exec form ENTRYPOINT example | ||||||||
|
|
||||||||
| You can use the exec form of `ENTRYPOINT` to set fairly stable default commands | ||||||||
|
|
@@ -2370,9 +2374,39 @@ The table below shows what command is executed for different `ENTRYPOINT` / `CMD | |||||||
| | **CMD exec_cmd p1_cmd** | /bin/sh -c exec_cmd p1_cmd | /bin/sh -c exec_entry p1_entry | exec_entry p1_entry /bin/sh -c exec_cmd p1_cmd | | ||||||||
|
|
||||||||
| > [!NOTE] | ||||||||
| > If `CMD` is defined from the base image, setting `ENTRYPOINT` will | ||||||||
| > reset `CMD` to an empty value. In this scenario, `CMD` must be defined in the | ||||||||
| > current image to have a value. | ||||||||
| > Setting `ENTRYPOINT` discards any `CMD` inherited from the base image. The | ||||||||
| > build stage that sets `ENTRYPOINT` must define its own `CMD` for the image to | ||||||||
| > have one. The order of the two instructions doesn't matter: a `CMD` in the | ||||||||
| > same stage is kept whether it appears before or after `ENTRYPOINT`. | ||||||||
|
Comment on lines
+2379
to
+2380
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'd rather drop this since it's irrelevant.
Suggested change
|
||||||||
|
|
||||||||
| This is easy to miss when you add an entrypoint wrapper to a base image that | ||||||||
| only defines a `CMD`. The following Dockerfile produces an image with no `CMD` | ||||||||
| at all, because the `nginx` image supplies its command as a `CMD`, and setting | ||||||||
| `ENTRYPOINT` discards it: | ||||||||
|
|
||||||||
| ```dockerfile | ||||||||
| FROM nginx | ||||||||
| COPY entrypoint.sh / | ||||||||
| ENTRYPOINT ["/entrypoint.sh"] | ||||||||
| ``` | ||||||||
|
|
||||||||
| A wrapper script ending in `exec "$@"` receives no arguments here, so it runs | ||||||||
| `exec` with nothing to execute, falls through to the end of the script, and the | ||||||||
| container exits immediately. Restate the command to keep the base image's | ||||||||
| behavior: | ||||||||
|
|
||||||||
| ```dockerfile | ||||||||
| FROM nginx | ||||||||
| COPY entrypoint.sh / | ||||||||
| ENTRYPOINT ["/entrypoint.sh"] | ||||||||
| CMD ["nginx", "-g", "daemon off;"] | ||||||||
| ``` | ||||||||
|
|
||||||||
| To check what a base image sets, inspect its configuration: | ||||||||
|
|
||||||||
| ```console | ||||||||
| $ docker image inspect --format '{{json .Config.Cmd}}' nginx | ||||||||
| ``` | ||||||||
|
Comment on lines
+2382
to
+2409
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think this is too specific for the Dockerfile reference. The note above already documents the general behavior. This turns that into troubleshooting for one particular wrapper-script pattern. Can we remove this example and the inspection command, and keep the concise explanation of the inherited CMD behavior above? If this needs a worked example, a synthetic base image would demonstrate the rule more accurately, but I don’t think the reference needs that level of detail. |
||||||||
|
|
||||||||
| ## VOLUME | ||||||||
|
|
||||||||
|
|
||||||||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.