docker
[BUG] `exec` command hijacks containers created with `run`
Description
When running a project using docker compose up and subsequently creating a one-off container using docker compose run <service>, running docker exec <service> will use the one-off container if a) it is newer than the managed container or b) the managed container is not running.
Steps To Reproduce
Using the following docker-compose.yaml:
services:
bug:
image: alpine
command: "sleep infinity"
Run the following commands:
docker compose up --detach
docker compose run --detach bug yes
docker compose exec bug ps -ef
docker compose down
docker compose exec bug ps -ef
The output of both exec commands should show yes in the process list, indicating that it's running within the one-off container. I would expect it to either a) run in the managed container (sleep would be in the process list) or b) print service "bug" is not running and exit.
Compose Version
Docker Compose version v2.27.1-desktop.1
Docker Environment
Client:
Version: 26.1.4
Context: default
Debug Mode: false
Plugins:
buildx: Docker Buildx (Docker Inc.)
Version: v0.14.1-desktop.1
Path: /usr/local/lib/docker/cli-plugins/docker-buildx
compose: Docker Compose (Docker Inc.)
Version: v2.27.1-desktop.1
Path: /usr/local/lib/docker/cli-plugins/docker-compose
debug: Get a shell into any image or container (Docker Inc.)
Version: 0.0.32
Path: /usr/local/lib/docker/cli-plugins/docker-debug
dev: Docker Dev Environments (Docker Inc.)
Version: v0.1.2
Path: /usr/local/lib/docker/cli-plugins/docker-dev
extension: Manages Docker extensions (Docker Inc.)
Version: v0.2.24
Path: /usr/local/lib/docker/cli-plugins/docker-extension
feedback: Provide feedback, right in your terminal! (Docker Inc.)
Version: v1.0.5
Path: /usr/local/lib/docker/cli-plugins/docker-feedback
init: Creates Docker-related starter files for your project (Docker Inc.)
Version: v1.2.0
Path: /usr/local/lib/docker/cli-plugins/docker-init
sbom: View the packaged-based Software Bill Of Materials (SBOM) for an image (Anchore Inc.)
Version: 0.6.0
Path: /usr/local/lib/docker/cli-plugins/docker-sbom
scout: Docker Scout (Docker Inc.)
Version: v1.9.3
Path: /usr/local/lib/docker/cli-plugins/docker-scout
Server:
Containers: 14
Running: 12
Paused: 0
Stopped: 2
Images: 12
Server Version: 26.1.4
Storage Driver: overlay2
Backing Filesystem: extfs
Supports d_type: true
Using metacopy: false
Native Overlay Diff: true
userxattr: false
Logging Driver: json-file
Cgroup Driver: cgroupfs
Cgroup Version: 2
Plugins:
Volume: local
Network: bridge host ipvlan macvlan null overlay
Log: awslogs fluentd gcplogs gelf journald json-file local splunk syslog
Swarm: inactive
Runtimes: io.containerd.runc.v2 runc
Default Runtime: runc
Init Binary: docker-init
containerd version: d2d58213f83a351ca8f528a95fbd145f5654e957
runc version: v1.1.12-0-g51d5e94
init version: de40ad0
Security Options:
seccomp
Profile: unconfined
cgroupns
Kernel Version: 6.6.31-linuxkit
Operating System: Docker Desktop
OSType: linux
Architecture: aarch64
CPUs: 4
Total Memory: 7.658GiB
Name: docker-desktop
ID: d3b97490-c8a4-4efb-8bf6-f1c01590a764
Docker Root Dir: /var/lib/docker
Debug Mode: false
HTTP Proxy: http.docker.internal:3128
HTTPS Proxy: http.docker.internal:3128
No Proxy: hubproxy.docker.internal
Labels:
com.docker.desktop.address=unix://<redacted>/Library/Containers/com.docker.docker/Data/docker-cli.sock
Experimental: false
Insecure Registries:
hubproxy.docker.internal:5555
127.0.0.0/8
Live Restore Enabled: false
Anything else?
Possibly related: #10359
I'm not sure if it's a bug or not but I changed the logic so if we have both containers(non one-off and one-off), then choose the non one-off container.
https://github.com/docker/compose/pull/11995
Actually docker compose exec should not target one-off containers, this seems like a bug we introduced, maybe some user start to rely on so #11995 could be a reasonable workaround
@examosa The issue seems to have been solved. If you encounter other related problems with this issue please re-open this.
