control-z exits interactive session

[jsberg-bnl]

• [X] I have tried with the latest version of my channel (Stable or Edge)
• [X] I have uploaded Diagnostics
• Diagnostics ID: 758075A2-293D-4061-BEC1-F876A57333AD/20200724163603

Expected behavior

Typing control-z in an interactive session should suspend the current process, or do nothing at a shell prompt

Actual behavior

If run via exec: unconditionally exits the docker process and returns you to the Windows console. If run via run: hangs that session; you can get a Windows console prompt back with ctrl-c, and can attach to the process again.

Information

• Windows Version: Windows 10 Pro 1909
• Docker Desktop Version: 2.3.0.3
• Are you running inside a virtualized Windows e.g. on a cloud server or on a mac VM: No

Steps to reproduce the behavior

All this done from a Windows console (cmd, PowerShell, Windows Terminal, doesn't matter):

1. docker run -tid --name test centos
2. docker exec -ti test /bin/bash
3. Type ctrl-z
4. docker exits back to the console, leaving the exec'd bash still running

[thaJeztah]

I suspect this may be related to https://github.com/moby/moby/issues/9098

[jsberg-bnl]

The part of the exec'd process being left behind may be, but the primary issue here is the fact that control-z is getting intercepted before it can do the usual Unix thing of stopping the process, and the docker interactive session (or whatever the right term is) is instead exited.

[thaJeztah]

Yes, (IIRC) part of the linked issue is related to signals not being proxied/forwarded to the exec'd proces

[jsberg-bnl]

It would be good if someone could try to reproduce this on a Linux host (sorry, don't have one). I've seen the issue mentioned a couple times before and it's always with a Windows host (for which control-z is and EOF character). So I'm wondering if it is an input handling issue on the Go end. There was some discussion a while back for how Go should handle control-z from Windows so as to generate an EOF, it's not clear to me how that got resolved.

[thaJeztah]

Tried on a Linux VM, and there CTRL-Z doesn't appear to trigger the exec to exit; this could be a configuration issue though. CTRL-Z on Linux can send a SIGSTP (20) signal. If I manually send that signal to the docker exec process, it does get stopped);

In one shell;

docker run -it --name test centos

Start docker exec in another shell;

docker exec -it test /bin/bash

In the first shell, check that two Bash processes are now running in the container;

ps aux
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root         1  0.0  0.3  12020  3264 pts/0    Ss   13:40   0:00 /bin/bash
root        14  0.0  0.3  12020  3232 pts/1    Ss+  13:41   0:00 /bin/bash
root        28  0.0  0.3  44596  3412 pts/0    R+   13:44   0:00 ps aux

Find the process of the docker exec;

ps aux | grep docker\ exec
root     12037  0.0  6.2 710136 62976 pts/1    Sl+  13:41   0:00 docker exec -ti test /bin/bash
root     12249  0.0  0.1  13136  1092 pts/2    S+   13:43   0:00 grep --color=auto docker exec

Send signal 20 to the process;

kill -s 20 12037

(the interactive docker exec now "exits"), but the process is still there, but TI ("stopped": https://linux.die.net/man/1/ps);

ps aux | grep docker\ exec
root     12037  0.0  6.2 710136 62976 pts/1    Tl   13:41   0:00 docker exec -ti test /bin/bash
root     12408  0.0  0.1  13136  1068 pts/2    S+   13:48   0:00 grep --color=auto docker exec

In the container, the bash process is still running;

ps aux
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root         1  0.0  0.3  12020  3268 pts/0    Ss   13:40   0:00 /bin/bash
root        14  0.0  0.3  12020  3232 pts/1    Ss+  13:41   0:00 /bin/bash
root        29  0.0  0.3  44596  3416 pts/0    R+   13:51   0:00 ps aux

Killing the docker exec process on the host;

kill -9 12037

Kills the docker exec process

ps aux | grep docker\ exec
root     12553  0.0  0.1  13136  1056 pts/2    S+   13:51   0:00 grep --color=auto docker exec

But the bash process that was started by it in the container is still running;

ps aux
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root         1  0.0  0.3  12020  3268 pts/0    Ss   13:40   0:00 /bin/bash
root        14  0.0  0.3  12020  3232 pts/1    Ss+  13:41   0:00 /bin/bash
root        30  0.0  0.3  44596  3404 pts/0    R+   13:52   0:00 ps aux

[docker-robott]

Issues go stale after 90 days of inactivity. Mark the issue as fresh with /remove-lifecycle stale comment. Stale issues will be closed after an additional 30 days of inactivity.

Prevent issues from auto-closing with an /lifecycle frozen comment.

If this issue is safe to close now please do so.

Send feedback to Docker Community Slack channels #docker-for-mac or #docker-for-windows. /lifecycle stale

[jsberg-bnl]

/remove-lifecycle stale

[jsberg-bnl]

/lifecycle frozen

[christiandavilakoobin]

I have the same problem, and is very annoying. Since it's almost a year since the original reporting, anyone know a workaround while this is fixed?

[ParkerHGordon]

Same thing here, running docker on windows 10, pressing ctrl-z while in emacs just made it freeze up instead of the expected behaviour.

[bpingris]

Any updates regarding this issue? Is that something that's being worked on? I would have thought that this is the expected behavior but we could overwrite it via the docker config file

[Sad-theFaceless]

I still have this issue, pressing Ctrl-Z will freeze the session no matter if I change the stty susp to another key, if I trap '' TSTP, or if I disable/enable job control with set +m/set -m. Nothing works. This is not new ( https://stackoverflow.com/questions/60907427/ctrlz-sigtstp-has-strange-behavior-in-bash-shell-in-docker-container )

[RobMackie]

/remove-lifecycle stale

[RobMackie]

I just hit this problem today. Very Very Annoying. How can I help fix it?

[lucmobz]

The only way I managed to get the correct behaviour for ctrl+z inside a linux docker container is by switching Windows PowerShell or CMD to legacy mode.

[Sad-theFaceless]

It indeed works in legacy mode, but at the price of the other useful console features...

[IgorArnaut]

Ctrl+z closes container instead of undoing changes in text editor inside a Linux container. Please fix this.

[Jonas-Wessner]

I also confirm this issue.

[Yolo390]

Hi there,

Same behaviour as well for me.

I am using Tmux with ctrl+z as keybinding. It freeze the container when I am using it...

Same if I run powershell as admin.

Is there a workaround to avoid it ?

Thanks !

[alexeyp0708]

Use Windows Terminal or Cmder or ConEmu and override (set) the CTRL+Z hotkey. Еhen the behavior of CTRL+Z will not affect the container Settings ConEmu or Cmder see https://stackoverflow.com/questions/60907427/ctrlz-sigtstp-has-strange-behavior-in-bash-shell-in-docker-container

[jsberg-bnl]

The problem is that there are cases where you want the CTRL-Z to get through (it's a stop signal to most programs), and this will prevent that.

[alexeyp0708]

The problem is that there are cases where you want the CTRL-Z to get through (it's a stop signal to most programs), and this will prevent that.

(edited) Run WSL in terminal And then work in the termenal through the wsl shell or run command for example wsl docker exec -it test bash

I suspect that docker in windows terminals commands via WSL with its own container. If you run docker in CMD, then docker will not detect the WSL shell, and launch itself through own container. And own container intermediary will simply catch stop/pause signals and apply them to itself.

https://learn.microsoft.com/ru-ru/windows/wsl/tutorials/wsl-containers https://docs.docker.com/desktop/wsl/

[alexeyp0708]

There are two ways for using docker cli in Windows. The Bash file C:\Program Files\Docker\Docker\resources\bin\docker determines whether the WSL container is used or not. If a WSL container is used, /usr/bin/docker will be launched (in C:\Program Files\Docker\Docker\resources\wsl\docker-wsl-cli.iso image). If the Windows shell is used, the file C:\Program Files\Docker\Docker\resources\bin\docker.exe will be launched.

To test these two ways, let's run first wsl C:\Program Files\Docker\Docker\resources\bin\docker.exe exec -it test bash (wsl "/mnt/c/Program Files/Docker/Docker/resources/bin/docker.exe" exec -it test bash) and then press CTRL+Z - the terminal will leave the container Then run wsl /usr/bin/docker exec -it test bash and then press CTRL+Z - the terminal will not leave the container. Conclusion - the problem is in docker.exe I think the problem is that when compiling the docker.exe file for Windows, the CTRL+Z combination was implemented by default to send a signal to stop the process docker.exe.

[alexeyp0708]

/remove-lifecycle frozen