detachKeys support (making Ctrl-P usable in attached containers) broken in v2?

[shabble]

Interactive/attached containers started with docker-compose v2.1.1 use Ctrl-P,Ctrl-Q as the detach escape sequence, regardless of detachKeys settings in ~/.docker/config.json

Previously discussed in #3311 and closed as fixed, but presumably broken again in the go rewrite?

docker-compose.yml:

services:
  blah:
    image: ubuntu:latest
    command: /bin/bash
    stdin_open: true
    tty: true

~/.docker/config.json:
{ "detachKeys": "z,z" }

Steps to reproduce the issue:

1. docker-compose run --rm blah
2. type z z (container detaches)
3. type Ctrl-p Ctrl-q (should not detach; does anyway.)

Describe the results you received:

detachKeys setting is in addition to the standard Ctrl-P,Ctrl-Q, not instead of. This leaves Ctrl-P inputs buffered making it unusable as an interactive keybinding (which is a common readline usage for 'previous thing')

Describe the results you expected:

interactive sessions opened through compose should obey the local detachKeys setting, or provide some other facility to configure it to avoid buffering ctrl-P keystrokes. This could be an argument to docker-compose run mirroring the --detach-keys STR arg that docker run accepts.

Edit:

After some source diving and further testing, I originally thought it wsnt' being set at all, but it is actually allowing both the default /and/ the detachkeys config, which is nice if you want it bound to something else as well, but not if you want to free up the original binding for use.

Output of docker compose version: Docker Compose version v2.1.1

Output of docker info:

Client:
 Context:    default
 Debug Mode: false
 Plugins:
  app: Docker App (Docker Inc., v0.9.1-beta3)
  buildx: Build with BuildKit (Docker Inc., v0.6.3-docker)
  compose: Docker Compose (Docker Inc., v2.1.1)
  scan: Docker Scan (Docker Inc., v0.9.0)

Server:
 Containers: 6
  Running: 4
  Paused: 0
  Stopped: 2
 Images: 118
 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: cgroupfs
 Cgroup Version: 1
 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.runtime.v1.linux runc io.containerd.runc.v2
 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
 Kernel Version: 5.11.0-38-generic
 Operating System: Ubuntu 20.04.3 LTS
 OSType: linux
 Architecture: x86_64
 CPUs: 3
 Total Memory: 7.742GiB
 Name: hithere
 ID: 123
 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
 Default Address Pools:
   Base: 10.0.0.0/16, Size: 26

[x-yuri]

After some source diving and further testing, I originally thought it wsnt' being set at all, but it is actually allowing both the default /and/ the detachkeys config

What makes you think so? Although judging from how it works, that is so.

[sollidsnake]

I'm also facing this issue. I downgraded to v1 as a temporary workaround.

[Jakob-Koschel]

Same issue here:

Client:
 Context:    default
 Debug Mode: false
 Plugins:
  buildx: Docker Buildx (Docker Inc., v0.7.1)
  compose: Docker Compose (Docker Inc., v2.2.1)
  scan: Docker Scan (Docker Inc., v0.11.0)

Server:
 Containers: 8
  Running: 1
  Paused: 0
  Stopped: 7
 Images: 15
 Server Version: 20.10.11
 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: aarch64
 CPUs: 8
 Total Memory: 23.45GiB
 Name: docker-desktop
 ID: 123
 Docker Root Dir: /var/lib/docker
 Debug Mode: false
 HTTP Proxy: http.docker.internal:3128
 HTTPS Proxy: http.docker.internal:3128
 Registry: https://index.docker.io/v1/
 Labels:
 Experimental: false
 Insecure Registries:
  127.0.0.0/8
 Live Restore Enabled: false

my workaround is running docker compose run -d <name> and attaching again.

[x-yuri]

@Jakob-Koschel Can you elaborate? Before docker-compose run -d <name> Ctrl-p Ctrl-q detaches you from the container, and after, it doesn't? I'm running docker-compose-2.2.2, and docker-20.10.11. As you might see, docker-compose in my case is a separate binary.

UPD Even if I run it your way, Ctrl-p Ctrl-q is still in effect.

[Jakob-Koschel]

well detachKeys is taken from ~/.docker/config.json when running docker directly, it only seems broken with docker-compose. So I'm starting the container through docker-compose and detach with -d and then I reattach through docker and then detachKeys is considered and works as it should.

I tried this with: docker attach $(docker compose run --rm -d <name>) which however is missing certain output and doesn't take certain input. Copying the output of docker compose run --rm -d <name> manually into docker attach worked though To automate this I had to do another workaround:

docker compose run --rm -d <name>
docker attach $(docker compose ps -a -q)

for this I had to make sure there are no other containers running in that docker compose.

I have little experience with docker-compose and really hope there is a better way.

[x-yuri]

I see. I don't run shells in containers like in the OP. So I don't really know the workflow people follow in that case. The way that OP did it, that would run a second instance of the blah service. Than, what's the point of running a shell in a container, if you launch another instance of a service anyway? Usually I have a container with some program and I run a shell there with exec if I need to investigate something. The way I see it, docker-compose run is for scripts (e.g. npm i), not for shells. But anyway:

version: '3'
services:
  s1:
    image: alpine
    command: /bin/sh
    stdin_open: true
    tty: true
  s2:
    image: alpine
    command: sleep infinity
    init: true

$ docker-compose up -d
$ docker-compose run --rm s1

If I press Ctrl-p Ctrl-q the docker-compose process stops responding and I have to kill it. And z z works (Ctrl-@ Ctrl-@ in my case).

$ docker-compose exec --rm s2 sh

Both Ctrl-p Ctrl-q and Ctrl-@ Ctrl-@ detach me from the container.

$ docker attach $(docker-compose ps -q s1)

This way it works as expected (Ctrl-@ Ctrl-@ detaches, Ctrl-p Ctrl-q doesn't).

$ docker exec -it $(docker-compose ps -q s2) sh

Same here.

So docker-compose run and docker-compose exec doesn't work as expected. The workaround is to use docker exec or docker attach.

And about shells in containers I recommend against command: /bin/bash or something. It makes things harder. There's no docker-compose attach, for one. Do you need to run a shell in a container with some program? docker-compose exec. Are you planning not run anything in a container right away? command: sleep infinity + init: true (to make it restart fast). Then docker-compose exec when you need a shell there. To make it clear I don't have projects with command: sleep infinity in docker-compose.yml files (not on the remote/origin). I usually change the command locally to sleep infinity, then exec into the container, then either run the process that is supposed to run there (e.g. ./manage.py runserver, bin/rails s), or vim, or whatever else I need (e.g. ./manage.py migrate, bin/rails db:migrate). This way I can also use interactive debuggers (e.g. pdbpp, pry-byebug). If I only need to restart the process, and there's a way (e.g. nginx -s reload), I just exec into the container (no point in changing the command).

[Jakob-Koschel]

Thanks for the input!

Let's revert back to the original issue: I've done some testing detachKeys is considered with docker-compose but Ctrl-p Ctrl-q is not 'released' (it should have no special behavior at this point). When I do this the shell just completely freezes.

[stale[bot]]

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]]

This issue has been automatically closed because it had not recent activity during the stale period.

[stale[bot]]

This issue has been automatically closed because it had not recent activity during the stale period.