compose doesn't show error or exit if depends_on service has exited

[rfay]

Description

In a compose project using depends_on, for example

services:
  web:
    image: busybox
    command: tail -f /dev/null
    depends_on:
      db:
        condition: service_healthy
  db:
    image: busybox
    command: sh -c "exit 1"

if the depends_on service exits before the healthcheck gets done running (apparently) then docker-compose up hangs forever waiting for it.

Steps to reproduce the issue:

Use the above docker-compose.yaml and docker-compose up -d

You'll get output like this:

$ docker-compose up -d
[+] Running 2/3
 ⠿ Network junk_default  Created                                                                        0.0s
 ⠿ Container junk-db-1   Waiting                                                                        6.2s
 ⠿ Container junk-web-1  Created

Describe the results you received:

docker-compose hangs forever. It doesn't daemonize, doesn't recognize that the db container has exited.

If a container it's depending on has exited, it should exit.

Describe the results you expected:

I would expect a failure if we're depending on a service that exits.

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

I think this doesn't fail this way if a healtcheck runs quickly and before the container exits. For example, if the container we're depending on has a healthcheck that shows unhealthy before the container exits, compose does the right thing.

Output of docker compose version:

Docker Compose version v2.7.0

I tested with a couple versions from 2.5.1 to 2.9.0 and got the same results

Output of docker info:

Client:
 Cloud integration: v1.0.28
 Version:           20.10.17
 API version:       1.41
 Go version:        go1.17.11
 Git commit:        100c701
 Built:             Mon Jun  6 23:04:45 2022
 OS/Arch:           darwin/arm64
 Context:           default
 Experimental:      true

Server: Docker Desktop 4.11.1 (84025)
 Engine:
  Version:          20.10.17
  API version:      1.41 (minimum version 1.12)
  Go version:       go1.17.11
  Git commit:       a89b842
  Built:            Mon Jun  6 23:01:01 2022
  OS/Arch:          linux/arm64
  Experimental:     false
 containerd:
  Version:          1.6.6
  GitCommit:        10c12954828e7c7c9b6e0ea9b0c02b01407d3ae1
 runc:
  Version:          1.1.2
  GitCommit:        v1.1.2-0-ga916309
 docker-init:
  Version:          0.19.0
  GitCommit:        de40ad0

Additional environment details:

[sirikon]

Can report the exact same problem. It hangs even including --abort-on-container-exit.

Just copying @rfay snippet in a folder and running docker compose up --abort-on-container-exit reproduces the issue.

$ docker compose version
Docker Compose version v2.12.2

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

Server:
 Containers: 2
  Running: 0
  Paused: 0
  Stopped: 2
 Images: 6
 Server Version: 20.10.21
 Storage Driver: overlay2
  Backing Filesystem: extfs
  Supports d_type: true
  Native Overlay Diff: true
  userxattr: false
 Logging Driver: json-file
 Cgroup Driver: systemd
 Cgroup Version: 2
 Plugins:
  Volume: local
  Network: bridge host ipvlan macvlan null overlay
  Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog
 Swarm: inactive
 Runtimes: io.containerd.runc.v2 io.containerd.runtime.v1.linux runc
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: 1c90a442489720eec95342e1789ee8a5e1b9536f
 runc version: v1.1.4-0-g5fd4c4d
 init version: de40ad0
 Security Options:
  apparmor
  seccomp
   Profile: default
  cgroupns
 Kernel Version: 5.10.0-19-amd64
 Operating System: Debian GNU/Linux 11 (bullseye)
 OSType: linux
 Architecture: x86_64
 CPUs: 8
 Total Memory: 13.61GiB
 Name: srk
 ID: 5XQM:S5NS:KXPC:NBJA:R3DO:K2CK:XCLM:R5AU:7RNB:KM3S:E226:JKG4
 Docker Root Dir: /var/lib/docker
 Debug Mode: false
 Username: sirikon
 Registry: https://index.docker.io/v1/
 Labels:
 Experimental: false
 Insecure Registries:
  127.0.0.0/8
 Live Restore Enabled: false

[jgould22]

Can confirm this happens on 2.13.0 as well

docker compose version
Docker Compose version 2.13.0

Client:
 Context:    default
 Debug Mode: false
 Plugins:
  compose: Docker Compose (Docker Inc., 2.13.0)

Server:
 Containers: 472
  Running: 7
  Paused: 0
  Stopped: 465
 Images: 244
 Server Version: 20.10.21
 Storage Driver: overlay2
  Backing Filesystem: extfs
  Supports d_type: true
  Native Overlay Diff: false
  userxattr: false
 Logging Driver: json-file
 Cgroup Driver: systemd
 Cgroup Version: 2
 Plugins:
  Volume: local
  Network: bridge host ipvlan macvlan null overlay
  Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog
 Swarm: inactive
 Runtimes: io.containerd.runc.v2 io.containerd.runtime.v1.linux runc
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: 770bd0108c32f3fb5c73ae1264f7e503fe7b2661.m
 runc version: 
 init version: de40ad0
 Security Options:
  seccomp
   Profile: default
  cgroupns
 Kernel Version: 6.0.9-arch1-1
 Operating System: EndeavourOS
 OSType: linux
 Architecture: x86_64
 CPUs: 8
 Total Memory: 15.5GiB
 Docker Root Dir: /var/lib/docker
 Debug Mode: false
 Registry: https://index.docker.io/v1/
 Labels:
 Experimental: false
 Insecure Registries:
  127.0.0.0/8
 Live Restore Enabled: false