Docker Compose 2.3.3 does not start subsidiary services called out in links

[mshappe]

Description

docker-compose v2.3.3 appears not to fully implement the dependency-starting behaviour of links.

services:
  foo:
    links:
      - bar

will create bar but not start it.

services:
  foo:
    depends_on:
      - bar
    links:
      - bar

will ensure bar gets started, but should be superfluous--linksis explicitly documented to implydepends_on`.

Steps to reproduce the issue:

See snippets above -- create a docker-compose.yml that uses links and not depends_on.

Describe the results you received:

Linked services that should be started are merely created.

Describe the results you expected:

Linked services are created and started, as prerequisites of the linking service, as if they had been called out in depends_on.

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

This behaviour was witnessed both on Arch Linux with docker-compose 2.3.3, and on macOS Docker Desktop 4.6.0

Output of docker compose version:

Docker Compose version 2.3.3

Output of docker info:

Client:
 Context:    default
 Debug Mode: false
 Plugins:
  buildx: Docker Buildx (Docker Inc., v0.8.0-docker)
  compose: Docker Compose (Docker Inc., 2.3.3)

Server:
 Containers: 15
  Running: 5
  Paused: 0
  Stopped: 10
 Images: 61
 Server Version: 20.10.13
 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.runtime.v1.linux runc io.containerd.runc.v2
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: 10f428dac7cec44c864e1b830a4623af27a9fc70.m
 runc version: v1.1.0-0-g067aaf85
 init version: de40ad0
 Security Options:
  seccomp
   Profile: default
  cgroupns
 Kernel Version: 5.16.15-arch1-1
 Operating System: Arch Linux
 OSType: linux
 Architecture: x86_64
 CPUs: 14
 Total Memory: 27.41GiB
 Name: archie
 ID: OKFG:RAZ6:H4RV:HRZU:RPEH:PMMT:3FA6:TSWT:BWX5:7PQA:W6T7:Y3PL
 Docker Root Dir: /var/lib/docker
 Debug Mode: false
 Username: betterupbot
 Registry: https://index.docker.io/v1/
 Labels:
 Experimental: false
 Insecure Registries:
  127.0.0.0/8
 Live Restore Enabled: false

[mshappe]

2.4.0 still contains this bug.

[ndeloof]

Ran a quick test with 2.4.0 trying to reproduce:

services:
  foo:
    image: nginx
    links:
      - bar
  bar:
    image: nginx

$ docker compose up -d
[+] Running 2/2
 ⠿ Container test-bar-1  Started                                           0.3s
 ⠿ Container test-foo-1  Started                                           0.3s
$ docker ps
CONTAINER ID   IMAGE     COMMAND                  CREATED         STATUS        PORTS     NAMES
e9e56c34b0ef   nginx     "/docker-entrypoint.…"   2 seconds ago   Up 1 second   80/tcp    test-foo-1
0619d071aea8   nginx     "/docker-entrypoint.…"   2 seconds ago   Up 1 second   80/tcp    test-bar-1

so, basically "can't reproduce".
Could you please try this minimal scenario, and maybe offer a more complete example demonstrating this issue?

[mshappe]

The main difference I see is that we don't call a blanket docker compose up -d, but rather, our script enumerates the "primary" services we want to run, e.g. docker compose up -d web worker spring frontend. Before version 2.3.3, this worked fine and actually started the linked services as well (e.g. db); now it doesn't.

Using your example above, if I call docker compose up -d foo, it reproduces the problem.

[mshappe]

docker compose -f zog.yml up -d foo
[+] Running 8/8
 ⠿ foo Pulled                                                                                                                                                                                                                         3.8s
   ⠿ fc0b36f3f49a Pull complete                                                                                                                                                                                                       2.0s
 ⠿ bar Pulled                                                                                                                                                                                                                         3.8s
   ⠿ 2203022c5aa9 Already exists                                                                                                                                                                                                      0.0s
   ⠿ 48ac378ef115 Pull complete                                                                                                                                                                                                       1.9s
   ⠿ b14df6d58994 Pull complete                                                                                                                                                                                                       1.9s
   ⠿ 93fe00d45e28 Pull complete                                                                                                                                                                                                       2.0s
   ⠿ 4dd9061d5c10 Pull complete                                                                                                                                                                                                       2.0s
[+] Running 3/3
 ⠿ Network michael_default  Created                                                                                                                                                                                                   0.0s
 ⠿ Container michael-bar-1  Created                                                                                                                                                                                                   0.1s
 ⠿ Container michael-foo-1  Started

[samdoran]

I am also hitting this issue with docker compose up -d. We have an nginx container that proxies to other running containers and the nginx container fails to start because the backend containers take longer to start up than nginx.

Adding depends_on with the exact contents of links works around this, exactly as described in the original report.

[ndeloof]

#9368 has been merged, so this should be fixed by next release