compose: `docker compose logs --follow` doesn't work

Steps to reproduce the issue:

  1. Run `docker compose logs --follow
  2. Notice the issue

Describe the results you received:

github.com/docker/compose-cli/local/compose.(*composeService).Logs.func1(0x0, 0x0)
	github.com/docker/compose-cli/local/compose/logs.go:54 +0x188
golang.org/x/sync/errgroup.(*Group).Go.func1(0xc000352cf0, 0xc0004b3860)
	golang.org/x/sync@v0.0.0-20210220032951-036812b2e83c/errgroup/errgroup.go:57 +0x59
created by golang.org/x/sync/errgroup.(*Group).Go
	golang.org/x/sync@v0.0.0-20210220032951-036812b2e83c/errgroup/errgroup.go:54 +0x66

Describe the results you expected:

  • To follow the logs

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

Output of docker version:

❯ docker version
Client:
 Cloud integration: 1.0.14
 Version:           20.10.6
 API version:       1.41
 Go version:        go1.16.3
 Git commit:        370c289
 Built:             Fri Apr  9 22:46:57 2021
 OS/Arch:           darwin/amd64
 Context:           default
 Experimental:      true

Server: Docker Engine - Community
 Engine:
  Version:          20.10.6
  API version:      1.41 (minimum version 1.12)
  Go version:       go1.13.15
  Git commit:       8728dd2
  Built:            Fri Apr  9 22:44:56 2021
  OS/Arch:          linux/amd64
  Experimental:     false
 containerd:
  Version:          1.4.4
  GitCommit:        05f951a3781f4f2c1911b05e61c160e9c30eaa8e
 runc:
  Version:          1.0.0-rc93
  GitCommit:        12644e614e25b05da6fd08a38ffa0cfe1903fdec
 docker-init:
  Version:          0.19.0
  GitCommit:        de40ad0

Output of docker context show:
You can also run docker context inspect context-name to give us more details but don’t forget to remove sensitive content.

❯ docker context show
default

Output of docker info:

❯ docker info
Client:
 Context:    default
 Debug Mode: false
 Plugins:
  app: Docker App (Docker Inc., v0.9.1-beta3)
  buildx: Build with BuildKit (Docker Inc., v0.5.1-docker)
  compose: Docker Compose (Docker Inc., 2.0.0-beta.1)
  scan: Docker Scan (Docker Inc., v0.6.0)

Server:
 Containers: 36
  Running: 30
  Paused: 0
  Stopped: 6
 Images: 30
 Server Version: 20.10.6
 Storage Driver: overlay2
  Backing Filesystem: extfs
  Supports d_type: true
  Native Overlay Diff: true
  userxattr: false
 Logging Driver: json-file
 Cgroup Driver: cgroupfs
 Cgroup Version: 1
 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: 05f951a3781f4f2c1911b05e61c160e9c30eaa8e
 runc version: 12644e614e25b05da6fd08a38ffa0cfe1903fdec
 init version: de40ad0
 Security Options:
  seccomp
   Profile: default
 Kernel Version: 5.10.25-linuxkit
 Operating System: Docker Desktop
 OSType: linux
 Architecture: x86_64
 CPUs: 6
 Total Memory: 14.65GiB
 Name: docker-desktop
 ID: 7KCQ:ORUH:7TCA:G2WV:5YNT:A5KW:6ONM:WWX4:GCN5:CAS5:TODK:SYDR
 Docker Root Dir: /var/lib/docker
 Debug Mode: false
 HTTP Proxy: http.docker.internal:3128
 HTTPS Proxy: http.docker.internal:3128
 Registry: https://index.docker.io/v1/
 Labels:
 Experimental: false
 Insecure Registries:
  127.0.0.0/8
 Live Restore Enabled: false

Additional environment details (AWS ECS, Azure ACI, local, etc.):

  • local

About this issue

  • Original URL
  • State: closed
  • Created 3 years ago
  • Reactions: 2
  • Comments: 16

Most upvoted comments

Just wanting to chime in that, while I’m not getting a panic, I am seeing similar behavior in Docker Compose version v2.0.0-rc.3. Running docker-compose logs --tail 100 --follow will display what appear to be the last 100 logs, but will not follow any new logs that are emitted.

Happy to report this as a separate issue with more information if you deem it to be its own problem!

might indeed be the simplest way, can also use IDE debuger. I sometime also configure socat to capture API calls to daemon.

@ndeloof The behavior of --follow is different from v1. In v1, a container shutting down caused logs --follow to exit. In v2, the follow continues to wait, with no more output. Even weirder, if the container is restarted, the old command doesn’t receive logs from the new container.