`docker compose run --entrypoint=EXECUTABLE SERVICENAME` fails to clear CMD

[fedde-s]

---

BUG REPORT INFORMATION

Description

If I run a one-off container based on a service definition using the run subcommand and override the entrypoint, Compose 2.6.0 fails to clear the default command (default arguments to the default entrypoint) as well. As far as I can think of, every other Docker interface to override the entrypoint also clears CMD:

• docker-compose run in v1
• the run subcommand of Docker itself:

Note: Passing --entrypoint will clear out any default command set on the image (i.e. any CMD instruction in the Dockerfile used to build it).

• Compose YAML files according to the Compose spec:

Compose implementations MUST clear out any default command on the Docker image - both ENTRYPOINT and CMD instruction in the Dockerfile - when entrypoint is configured by a Compose file.

• Older versions of the Compose YAML file format:

Note: Setting entrypoint both overrides any default entrypoint set on the service’s image with the ENTRYPOINT Dockerfile instruction, and clears out any default command on the image - meaning that if there’s a CMD instruction in the Dockerfile, it is ignored.

Steps to reproduce the issue:

1. Define a service with both an entrypoint and a default command to pass to it, e.g.

services:
  database:
    image: mysql:8.0
    command: ["--help"]

2. Run a docker compose run command that overrides the entrypoint with a different executable, e.g.

$ docker compose run --rm --entrypoint=ls database

Describe the results you received:

The new entrypoint, ls, responds as if it was passed the default arguments intended for the original entrypoint, namely the --help, flag, and prints a usage message.`

Describe the results you expected:

I expected the new entrypoint, ls, to be run without arguments and list the files in the container's working directory.

Additional information you deem important (e.g. issue happens only occasionally):

None.

Output of docker compose version:

Docker Compose version v2.6.0

Output of docker info:

Snippet:

Client:
 Context:    default
 Debug Mode: false
 Plugins
  app: Docker App (Docker Inc., v0.9.1-beta3)
  buildx: Docker Buildx (Docker Inc., v0.8.2-docker)
  compose: Docker Compose (Docker Inc., v2.6.0)
  scan: Docker Scan (Docker Inc., v0.17.0)

Server:
 Containers: 0
  Running: 0
  Paused: 0
  Stopped: 0
 Images: 10
 Server Version: 20.10.17
[...]
 Kernel Version: 5.4.0-121-generic
 Operating System: Linux Mint 20.2
 OSType: linux
 Architecture: x86_64
[...]

Additional environment details:

—

[totalhack]

Is there a suggested workaround for this?

It seems like this thread is possibly the same issue: #9483. But the suggested workaround there (using CMD in Dockerfile) doesn't provide the same functionality of being able to override with "command" at run-time, which I have been doing in a docker-compose.override.yml file to run a different command in development. This worked fine with v1, and I can't imagine why this is not a bug.

[fedde-s]

@totalhack:

Is there a suggested workaround for this?

If stuck with a Compose version that does not yet include the fix (releases prior to v2.11.2), I'd try to resolve it by looking if there's an argument that doesn't affect what the particular entrypoint command you're setting and explicitly set the command (=default arguments to the entrypoint) to that instead of expecting it to be empty. In the ls example I gave under Steps to reproduce, that could amount to replacing

$ docker compose run --rm --entrypoint=ls database

by

$ docker compose run --rm --entrypoint=ls database .

to effectively make the full command ls .. For some other commands, a single or double hyphen might be a good no-op argument list, if you're lucky.

[glours]

@totalhack @fedde-s the release of Compose v2.11.2 done yesterday should fix the issue, no workaround needed it should work without overriding the command

[fedde-s]

Thank you very much for the quick resolution of the core issue, @glours and @milas!