Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Regression on compose logs -f frozen wrt Ctrl-C #8977

Closed
Rogdham opened this issue Nov 29, 2021 · 2 comments
Closed

Regression on compose logs -f frozen wrt Ctrl-C #8977

Rogdham opened this issue Nov 29, 2021 · 2 comments
Assignees

Comments

@Rogdham
Copy link

Rogdham commented Nov 29, 2021

Description

Hello, this bug is a regression with docker compose logs -f.

It follows other similar bugs that have now been fixed, and appears in more edge cases (see #8715/#8726 #8880/#8926 and #8749).

@ndeloof you fixed those issues, could you please take a look at this one as well? 🙏


Steps to reproduce the issue:

  1. docker-compose.yml:
version: '2.2'

services:
  foo:
    image: alpine
    command: sh -c 'while true; do date; sleep 1; done'
  bar:
    image: alpine
    command: sh -c 'while true; do date; sleep 1; done'
  1. Run in first shell:
docker compose up -d
docker compose logs -f
  1. Run in second shell:
docker compose stop bar
docker compose restart foo
  1. Look at the logs -f in first shell, and do a Ctrl^C on it

Describe the results you received:

The logs -f command in first shell does not show the logs of the new foo container, and Ctrl^C does nothing (the process hangs).

Describe the results you expected:

The logs -f command in first shell should show the logs of the new foo container, and be able to exit properly on Ctrl^C


Output of docker compose version:

Docker Compose version 2.2.0

Output of docker info:

Click

yes, even hidden code blocks!

print("hello world!")
Client:
 Context:    default
 Debug Mode: false
 Plugins:
  buildx: Build with BuildKit (Docker Inc., v0.6.1-docker)
  compose: Docker Compose (Docker Inc., 2.2.0)

Server:
 Containers: 0
  Running: 0
  Paused: 0
  Stopped: 0
 Images: 270
 Server Version: 20.10.11
 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: 1e5ef943eb76627a6d3b6de8cd1ef6537f393a71.m
 runc version: v1.0.2-0-g52b36a2d
 init version: de40ad0
 Security Options:
  seccomp
   Profile: default
  cgroupns
 Kernel Version: 5.15.5-arch1-1
 Operating System: Arch Linux
 OSType: linux
 Architecture: x86_64
 CPUs: 8
 Total Memory: 15.49GiB
 Name: redacted
 ID: QWTG:NECD:SNJA:QID3:DH7O:66LK:AICG:CCWU:MYAX:HAA5:YFMA:C43I
 Docker Root Dir: /var/lib/docker
 Debug Mode: false
 Username: redacted
 Registry: https://index.docker.io/v1/
 Labels:
 Experimental: false
 Insecure Registries:
  127.0.0.0/8
 Live Restore Enabled: false

@Rogdham
Copy link
Author

Rogdham commented Dec 13, 2021

This issue seems to be fixed with docker compose version 2.2.2 🎉

Thank you @ndeloof 🤗

@michaeljmuller
Copy link

I'm seeing this behavior in Docker Compose version v2.14.1

@laurazard laurazard self-assigned this Jan 19, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants