compose icon indicating copy to clipboard operation
compose copied to clipboard

`Ctrl-C` no longer terminates `docker compose logs -f` after a `Ctrl-Z` is sent

Open dossy opened this issue 3 years ago • 1 comments

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:

  1. docker compose logs -f
  2. Press Ctrl-Z
  3. Press Ctrl-C one 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:

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

dossy avatar Mar 24 '22 23:03 dossy

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.

stale[bot] avatar Sep 21 '22 09:09 stale[bot]

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.

Lemmmy avatar Dec 18 '22 14:12 Lemmmy

For me this is fixed in the latest release https://github.com/docker/compose/releases/tag/v2.14.2, by commit 7cf6d5ec4eadc3a991d84c4df43fb7c7a70943cc.

tm604 avatar Dec 20 '22 09:12 tm604

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!

Lemmmy avatar Dec 20 '22 16:12 Lemmmy