compose: `docker compose logs --follow` doesn't work
Steps to reproduce the issue:
- Run `docker compose logs --follow
- 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
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
. Runningdocker-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.