Skip to content
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
40 changes: 37 additions & 3 deletions frontend/dockerfile/docs/reference.md
Original file line number Diff line number Diff line change
Expand Up @@ -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
Comment on lines +2132 to +2133

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
Setting `ENTRYPOINT` also discards any `CMD` inherited from the base image,
unless the same build stage defines its own `CMD`. For more information, see
Setting `ENTRYPOINT` also discards any `CMD` inherited from the base image.
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
Expand Down Expand Up @@ -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

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd rather drop this since it's irrelevant.

Suggested change
> 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`.
> have one.


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

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The 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

Expand Down