`Ctrl-C` no longer terminates `docker compose logs -f` after a `Ctrl-Z` is sent
Description
After sending docker compose logs -f a Ctrl-Z to try and suspend the process, the process is no longer cancelable using Ctrl-C, and can only be terminated by sending a SIGKILL (signal 9) signal, as SIGTERM (signal 15) nor SIGQUIT (signal 3) cause the process to terminate either.
Steps to reproduce the issue:
docker compose logs -f- Press
Ctrl-Z - Press
Ctrl-Cone or more times.
Describe the results you received:
Sadness and disappointment that the docker compose logs -f refuses to terminate.
Describe the results you expected:
docker compose logs -f terminates.
Additional information you deem important (e.g. issue happens only occasionally):
Sending the default SIGTERM (signal 15) signal to the process doesn't cause it to terminate, nor sending a SIGQUIT (signal 3), either. Only sending a SIGKILL (signal 9) does.
It appears that proper signal handling seems to be a persistent problem for the docker-compose tool:
- CTRL-C does not end compose logs -f #8880
- Regression on compose logs -f frozen wrt Ctrl-C #8977
- (Regression) Pressing CTRL+C on docker-compose up hangs when using containers with restart: unless-stopped|always #9003
Output of docker compose version:
$ docker compose version
Docker Compose version v2.2.3
Output of docker info:
$ docker info
Client:
Context: default
Debug Mode: false
Plugins:
buildx: Docker Buildx (Docker Inc., v0.7.1)
compose: Docker Compose (Docker Inc., v2.2.3)
scan: Docker Scan (Docker Inc., v0.17.0)
Server:
Containers: 8
Running: 8
Paused: 0
Stopped: 0
Images: 57
Server Version: 20.10.12
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: 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: runc io.containerd.runc.v2 io.containerd.runtime.v1.linux
Default Runtime: runc
Init Binary: docker-init
containerd version: 7b11cfaabd73bb80907dd23182b9347b4245eb5d
runc version: v1.0.2-0-g52b36a2
init version: de40ad0
Security Options:
seccomp
Profile: default
cgroupns
Kernel Version: 5.10.76-linuxkit
Operating System: Docker Desktop
OSType: linux
Architecture: x86_64
CPUs: 4
Total Memory: 7.774GiB
Name: docker-desktop
ID: N3BY:2QGJ:2RJK:42BH:KLQT:MG42:MWF2:JOSY:ONSK:HOMB:TKDE:FAJK
Docker Root Dir: /var/lib/docker
Debug Mode: false
HTTP Proxy: http.docker.internal:3128
HTTPS Proxy: http.docker.internal:3128
No Proxy: hubproxy.docker.internal
Registry: https://index.docker.io/v1/
Labels:
Experimental: false
Insecure Registries:
hubproxy.docker.internal:5000
127.0.0.0/8
Live Restore Enabled: false
Additional environment details:
N/A
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
I am experiencing a potentially similar(?) issue on a fresh (2 days old) installation of Docker on Ubuntu 22.04 (installation method). Unlike on my other identical deployments, docker compose logs -f [service] on this server requires three ^C presses to terminate, every time. Regardless of whether I press ^Z or not.
mysqld-exporter | ts=2022-12-18T14:34:21.586Z caller=tls_config.go:195 level=info msg="TLS is disabled." http2=false
^C^C^CERRO[0006] got 3 SIGTERM/SIGINTs, forcing shutdown
I can reproduce this with the following docker-compose.yml:
services:
mariadb:
image: mariadb
docker compose version
Docker Compose version v2.14.1
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
docker info
Client:
Context: default
Debug Mode: false
Plugins:
app: Docker App (Docker Inc., v0.9.1-beta3)
buildx: Docker Buildx (Docker Inc., v0.9.1-docker)
compose: Docker Compose (Docker Inc., v2.14.1)
scan: Docker Scan (Docker Inc., v0.23.0)
Server:
Containers: 25
Running: 18
Paused: 0
Stopped: 7
Images: 23
Server Version: 20.10.22
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: 78f51771157abb6c9ed224c22013cdf09962315d
runc version: v1.1.4-0-g5fd4c4d
init version: de40ad0
Security Options:
apparmor
seccomp
Profile: default
cgroupns
Kernel Version: 5.15.0-56-generic
Operating System: Ubuntu 22.04.1 LTS
OSType: linux
Architecture: x86_64
CPUs: 12
Total Memory: 62.73GiB
Name: hiroi
ID: KCVL:RENI:G574:TJU7:6HBJ:ZOMI:TPEL:3J27:M6LD:DS3R:MRUF:QXEC
Docker Root Dir: /var/lib/docker
Debug Mode: false
Registry: https://index.docker.io/v1/
Labels:
Experimental: false
Insecure Registries:
127.0.0.0/8
Live Restore Enabled: false
I am using the fish shell, but it happens if I change my shell to /bin/bash and /bin/sh too. I am using Windows Terminal, but it happens if I use OpenSSH in mingw (git bash) too. It may also be #8880 that I'm seeing.
For me this is fixed in the latest release https://github.com/docker/compose/releases/tag/v2.14.2, by commit 7cf6d5ec4eadc3a991d84c4df43fb7c7a70943cc.
For me this is fixed in the latest release https://github.com/docker/compose/releases/tag/v2.14.2, by commit 7cf6d5e.
Can confirm it's fixed, thanks!