CTRL-C does not end compose logs -f

[logopk]

CTRL-C does not end compose logs -f

This started with compose 2.1.0

Steps to reproduce the issue:

1. docker-compose logs -f containername
2. CTRL-C

whereas docker logs -f containername works as expected

Describe the results you received:
Command can only be killed

Describe the results you expected:
Return to shell

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

Output of docker compose version:

Docker Compose version 2.1.0

Output of docker info:

Client:
 Context:    default
 Debug Mode: false
 Plugins:
  buildx: Build with BuildKit (Docker Inc., v0.6.0)
  compose: Docker Compose (Docker Inc., 2.1.0)

Server:
 Containers: 5
  Running: 5
  Paused: 0
  Stopped: 0
 Images: 18
 Server Version: 20.10.10
 Storage Driver: overlay2
  Backing Filesystem: extfs
  Supports d_type: true
  Native Overlay Diff: true
  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: 5b46e404f6b9f661a205e28d59c982d3634148f8
 runc version: v1.0.2-0-g52b36a2
 init version: de40ad0
 Security Options:
  apparmor
  seccomp
   Profile: default
  cgroupns
 Kernel Version: 5.10.0-9-amd64
 Operating System: Debian GNU/Linux 11 (bullseye)
 OSType: linux
 Architecture: x86_64
 CPUs: 2
 Total Memory: 1.936GiB
 Name: debian
 ID: FJ7Z:235F:BJJA:OYFZ:6SRB:6XWR:U3JO:SCBH:EQ4G:G55K:2KQL:5JK2
 Docker Root Dir: /var/lib/docker
 Debug Mode: false
 Registry: https://index.docker.io/v1/
 Labels:
 Experimental: true
 Insecure Registries:
  127.0.0.0/8
 Live Restore Enabled: false
 Default Address Pools:
   Base: 172.16.0.0/16, Size: 24

Additional environment details:

[ndeloof]

ouch, this is a regression - seems to me I've fixed this at least twice in the past :P

[nocive]

Possible duplicate of #8749
@ndeloof I reported this very same problem back in early October and the issue persists even after the last change (#8726), with slightly different symptoms.

[sy6sy2]

I can confirm that to exit from a docker compose logs -f we need to press multiple times CTRL-C until we get a got 3 SIGTERM/SIGINTs, forcing shutdown. And it happens if services are still running.

docker compose version: docker Compose version v2.1.1

[nocive]

I wouldn't mind having to press CTRL^C multiple times for the time being, what bothers me the most is the stale process that is left behind as described in #8749.
At the moment compose logs is simply unusable without some kind of shell wrapper that ensures the process termination, eg:

trap cleanup EXIT

function cleanup() {
    if [ -n "$pid" ]; then
        pkill -P $pid --signal 9
        kill -9 $pid
    fi
}

docker compose logs --tail="${nr_lines}" ${opts[@]} ${sources} 2>&1 &
pid=$!
wait $pid

[ndeloof]

CTRL^C multiple times just kill the client.
This is definitively a bug.

If you're running on Docker Desktop, could you please try running com.docker.cli compose logs -f to reproduce this issue, in case there's any relation with badly named "compose-cli" that implements the docker command.

[dmp1ce]

On Arch Linux "docker-compose logs -f" cannot be exited with multiple CTRL-C but "docker compose logs -f" can be exited with three CTRL-C.

[sy6sy2]

Using com.docker.cli compose logs -f, like docker compose logs -f, also leads to the got 3 SIGTERM/SIGINTs, forcing shutdown bug.

[davidmroth]

Same issue here on both Docker Desktop (Mac M1) and Docker installed on Ubuntu 20.04.3 LTS. (VM) ctrl+c doesn't stop logs

$ docker version

Client:
 Version:           20.10.8
 API version:       1.41
 Go version:        go1.16.6
 Git commit:        3967b7d28e
 Built:             Wed Aug  4 21:27:11 2021
 OS/Arch:           linux/arm64
 Context:           default
 Experimental:      true

Server:
 Engine:
  Version:          20.10.8
  API version:      1.41 (minimum version 1.12)
  Go version:       go1.16.6
  Git commit:       75249d8
  Built:            Wed Aug  4 21:28:41 2021
  OS/Arch:          linux/arm64
  Experimental:     false
 containerd:
  Version:          v1.4.9
  GitCommit:        e25210fe30a0a703442421b0f60afac609f950a3
 runc:
  Version:          1.0.1
  GitCommit:        
 docker-init:
  Version:          0.19.0
  GitCommit:        de40ad0

$ docker-compose version

Docker Compose version v2.1.1

[slhck]

Thanks for the fix, this bug was driving me insane. Any ETA on when this will be released?

[Rogdham]

@slhck released as of version 2.2.0.

However the issue is not completely fixed, see #8977.

[crux]

I have the same issues with docker logs -f .... (without the compose).

BUT! com.docker.cli works with a Ctrl-C.

BUT! What about Ctrl-Z ? When I do a docker logs -f ... it kind of works with a Ctrl-C, but when I try to do a Ctrl-Z before, any Ctrl-C after that will fail.

cmd.docker.cli is an improvement over this, but still, I would like to use full job control, with Ctrl-Z backgrounding the process. WTF is going on here?

[notDavid]

Fyi i'm still having this issue... CTRL^C multiple times does not work either, neither does CTRL^Z

Docker Compose version v2.5.0
Ubuntu 22.04 LTS, x86_64

[Radiergummi]

Still experiencing this...

[garritfra]

Not sure if this is related, but I just started seeing this problem when trying to exit a regular docker-compose up.

[jspiers]

I'm seeing this same bug (i.e. after starting containers using docker compose up -d and viewing logs with docker logs -f <container_name>, I need 3 Ctrl-C keypresses to quit viewing the logs, and this results in an orphaned "docker-compose" process).

$ docker version
Client: Docker Engine - Community
 Version:           20.10.22
 API version:       1.41
 Go version:        go1.18.9
 Git commit:        3a2c30b
 Built:             Thu Dec 15 22:28:04 2022
 OS/Arch:           linux/amd64
 Context:           default
 Experimental:      true

Server: Docker Engine - Community
 Engine:
  Version:          20.10.22
  API version:      1.41 (minimum version 1.12)
  Go version:       go1.18.9
  Git commit:       42c8b31
  Built:            Thu Dec 15 22:25:49 2022
  OS/Arch:          linux/amd64
  Experimental:     false
 containerd:
  Version:          1.6.13
  GitCommit:        78f51771157abb6c9ed224c22013cdf09962315d
 runc:
  Version:          1.1.4
  GitCommit:        v1.1.4-0-g5fd4c4d
 docker-init:
  Version:          0.19.0
  GitCommit:        de40ad0

[Lemmmy]

and this results in an orphaned "docker-compose" process

Oh wow, you weren't kidding

[lungj]

Does SIGQUIT (CTRL+) leave any orphans for you @Lemmmy ?

[Lemmmy]

No, it does not

[jonwest]

Having the same issue here with both docker compose logs -f and docker compose up.

[gertcuykens]

same issue
Docker Compose version v2.14.1
Client: Docker Engine - Community
Version: 20.10.22
API version: 1.41
Go version: go1.18.9
Git commit: 3a2c30b
Built: Thu Dec 15 22:28:22 2022
OS/Arch: linux/amd64
Context: default
Experimental: true

[ndeloof]

This has been fixed in 2.14.2, see #10104

[garritfra]

@ndeloof thanks, I can confirm that the issue is fixed.

[ndeloof]

👍

[oxxxxxy]

lol, nope.

@ndeloof thanks, I can confirm that the issue is fixed.