Log tailing leaves behind a stale process when CTRL^C is used and the target container is not running

[nocive]

Description

Steps to reproduce the issue:

1. terminal 1: docker compose logs -f SOME_CONTAINER
2. terminal 2: docker compose stop SOME_CONTAINER
3. terminal 1: Hit CTRL^C

Describe the results you received:
A zombie docker-compose logs process is left running with PPID 1 that needs to be force killed to be stopped

xxx  153806       1  1 08:52 pts/0    00:00:00 /home/xxx/.docker/cli-plugins/docker-compose compose logs --tail=30 -f -t xxx

Describe the results you expected:
No leftover processes after hitting CTRL^C

Additional information you deem important (e.g. issue happens only occasionally):
Consistently reproducible, happens with all versions of docker compose 2.x.

Output of docker compose version:

Docker Compose version v2.0.1

Output of docker info:

Client:
 Context:    default
 Debug Mode: false
 Plugins:
  buildx: Build with BuildKit (Docker Inc., v0.6.1-docker)
  compose: Docker Compose (Docker Inc., v2.0.1)

Server:
 Containers: 90
  Running: 48
  Paused: 0
  Stopped: 42
 Images: 160
 Server Version: 20.10.8
 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: 72cec4be58a9eb6b2910f5d10f1c01ca47d231c0.m
 runc version: v1.0.2-0-g52b36a2d
 init version: de40ad0
 Security Options:
  seccomp
   Profile: default
  cgroupns
 Kernel Version: 5.14.7-arch1-1
 Operating System: Antergos Linux
 OSType: linux
 Architecture: x86_64
 CPUs: 4
 Total Memory: 15.5GiB
 Name: jps-x1
 ID: TX6D:ALDF:OGX5:HVBY:YJNY:FLH2:GRJI:I52W:V3K3:L6ZT:S2YY:23UM
 Docker Root Dir: /var/lib/docker
 Debug Mode: false
 Username: nocive
 Registry: https://index.docker.io/v1/
 Labels:
 Experimental: true
 Insecure Registries:
  127.0.0.0/8
 Live Restore Enabled: false

[nocive]

Possibly related issues: #8564

[nocive]

Possible fix provided in #8726 ?

[nocive]

Fixed in 2.1.0 by #8726, closing.

[nocive]

The issue persists if the container isn't running before docker compose logs is ran.

[nocive]

new attempt: #8926

[nocive]

Seems to be solved in latest pre release.
Since no one bothered to check or track this issue, i'll close it myself.

[Rogdham]

If I'm not mistaken #8926 is included in 2.2.0, but I still have the issue in that version in some cases.

@nocive could you reproduce? It's harder than before, but with the following scenario I have the issue every single time.

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'

commands:

# first shell
$ docker-compose up -d
$ docker-compose logs -f

# second shell
$ docker-compose stop bar
$ docker-compose restart foo

After the last command, the logs in first shell should show the logs of the new containers, but instead show nothing, and Ctrl^C does nothing as well (the process hangs).

[nocive]

I can't reproduce.
As soon as the container is stopped, my logs command bails out on its own.

[Rogdham]

Hmm that's bizarre, when you stop bar you should still see the logs for foo, right?

Or do you mean that when you restart foo then the logs command exits? In which case adding a third container could help maybe.

Do you think I should open a new ticket?

[nocive]

@Rogdham to be fair, I didn't follow your exact reproduction steps and only tested this with a single container, which is also what's in this issue's description.

Do you think I should open a new ticket?

Perhaps that would be best, also because this one is not getting any attention from the maintainers :')
That said, I'm also happy to re-open this one if you think the issue still accurately describes the problem you're facing.

[Rogdham]

ok, created in #8977, thank you for your feedback!