Shell exits before accepting command when using --init option

[uk-ar]

• I have tried with the latest version of Docker Desktop
• I have tried disabling enabled experimental features
• I have uploaded Diagnostics
• Diagnostics ID: E8B1A495-7656-487E-BCCE-922AE82AEA48/20210521091209

Expected behavior

Shell accepts command even if using --init option

$ sudo docker run -it --init ubuntu
root@6eed550e8eab:/# exit
exit

Actual behavior

Shell exits before accepting command when using --init option

docker run --init -it ubuntu
root@e43bc9b185ec:/# e%

Information

• Is it reproducible? Yes
• Is the problem new? Yes
• Did the problem appear with an update? Not sure, but it works as I expected on Linux.
• A reproducible case if this is a bug, Dockerfiles FTW. Public ubuntu image.
• macOS Version: 11.3.1
• Intel chip or Apple chip: Apple M1
• Docker Desktop Version:

% docker version
Client: Docker Engine - Community
 Version:           20.10.6
 API version:       1.41
 Go version:        go1.16.3
 Git commit:        370c289
 Built:             Mon Apr 12 13:01:13 2021
 OS/Arch:           darwin/arm64
 Context:           default
 Experimental:      true

Server: Docker Engine - Community
 Engine:
  Version:          20.10.6
  API version:      1.41 (minimum version 1.12)
  Go version:       go1.13.15
  Git commit:       8728dd2
  Built:            Fri Apr  9 22:44:13 2021
  OS/Arch:          linux/arm64
  Experimental:     false
 containerd:
  Version:          1.4.4
  GitCommit:        05f951a3781f4f2c1911b05e61c160e9c30eaa8e
 runc:
  Version:          1.0.0-rc93
  GitCommit:        12644e614e25b05da6fd08a38ffa0cfe1903fdec
 docker-init:
  Version:          0.19.0
  GitCommit:        de40ad0

Steps to reproduce the behavior

1. docker run --init -it ubuntu
2. input any charactor

[stephen-turner]

Hmmm, I can't repro this, I get the shell prompt as expected.

[stephen-turner]

I'm on an Intel Mac but my colleague on an M1 Mac can't repro it either. We're trying to see if we can see anything in your logfiles to explain it.

[djs55]

It doesn't reproduce for me either, but I'm suspicious about these logs:

2021-05-21 18:01:39.972896+0900  localhost com.docker.driver.amd64-linux[87081]: proxy >> POST /v1.41/containers/b6e4ab5bb7d4271bae2ad14dfce139f9b0e84f315ae6e9fdac8224cd93c0b780/kill?signal=URG
2021-05-21 18:01:40.011035+0900  localhost com.docker.driver.amd64-linux[87081]: proxy << POST /v1.41/containers/b6e4ab5bb7d4271bae2ad14dfce139f9b0e84f315ae6e9fdac8224cd93c0b780/kill?signal=URG (38.671584ms)
2021-05-21 18:01:40.023126+0900  localhost com.docker.driver.amd64-linux[87081]: proxy >> GET /system/df
2021-05-21 18:01:40.023478+0900  localhost com.docker.driver.amd64-linux[87081]: proxy >> POST /v1.41/containers/b6e4ab5bb7d4271bae2ad14dfce139f9b0e84f315ae6e9fdac8224cd93c0b780/kill?signal=URG
2021-05-21 18:01:40.046166+0900  localhost com.docker.driver.amd64-linux[87081]: proxy << POST /v1.41/containers/b6e4ab5bb7d4271bae2ad14dfce139f9b0e84f315ae6e9fdac8224cd93c0b780/kill?signal=URG (23.016666ms)
2021-05-21 18:01:40.046463+0900  localhost com.docker.driver.amd64-linux[87081]: proxy >> POST /v1.41/containers/b6e4ab5bb7d4271bae2ad14dfce139f9b0e84f315ae6e9fdac8224cd93c0b780/kill?signal=URG
2021-05-21 18:01:40.065823+0900  localhost com.docker.driver.amd64-linux[87081]: proxy << POST /v1.41/containers/b6e4ab5bb7d4271bae2ad14dfce139f9b0e84f315ae6e9fdac8224cd93c0b780/kill?signal=URG (19.344083ms)
2021-05-21 18:01:40.066045+0900  localhost com.docker.driver.amd64-linux[87081]: proxy >> POST /v1.41/containers/b6e4ab5bb7d4271bae2ad14dfce139f9b0e84f315ae6e9fdac8224cd93c0b780/kill?signal=URG
2021-05-21 18:01:40.081146+0900  localhost com.docker.driver.amd64-linux[87081]: proxy << POST /v1.41/containers/b6e4ab5bb7d4271bae2ad14dfce139f9b0e84f315ae6e9fdac8224cd93c0b780/kill?signal=URG (15.082833ms)

I don't think these signals should be sent. Depending on when they arrive, they could possibly terminate the shell process. I see them locally too, but the timing is probably different.

[djs55]

@uk-ar I have an experimental build of the Docker CLI if you'd like to try it. Unfortunately CircleCI is currently down so I can't point you at a CI build.

If you'd like to try the experimental version, it can be built from this PR: docker/cli#3103 . Alternatively I've built it on Apple Silicon, here is my pre-built binary:

docker-darwin-arm64.zip

You can verify it by:

dave@m1 /tmp % unzip docker-darwin-arm64.zip 
Archive:  docker-darwin-arm64.zip
  inflating: build/docker-darwin-arm64  
dave@m1 /tmp % shasum build/docker-darwin-arm64 
cdc84f61264421078cf99fd0ce918e6e8ece0950  build/docker-darwin-arm64

and then you can test it by:

dave@m1 /tmp % ./build/docker-darwin-arm64 run -it --init ubuntu
root@07df376c0a10:/# 
root@07df376c0a10:/# 
root@07df376c0a10:/# exit
exit

Let me know if that works better or not. If it still fails, could you upload a fresh set of diagnostics? Thanks!

[uk-ar]

@stephen-turner @djs55 Thank you for your response and investigation.

I tried David's build on zsh, on bash,on iTerm2 and Apple's terminal, but it still all fails

$ unzip docker-darwin-arm64.zip
Archive:  docker-darwin-arm64.zip
  inflating: build/docker-darwin-arm64
$ shasum build/docker-darwin-arm64
cdc84f61264421078cf99fd0ce918e6e8ece0950  build/docker-darwin-arm64

zsh$ ./build/docker-darwin-arm64 run -it --init ubuntu
zsh: killed     ./build/docker-darwin-arm64 run -it --init ubuntu

bash$ ./build/docker-darwin-arm64 run -it --init ubuntu
Killed: 9

Even if I remove --init option, I couldn't open shell.

./build/docker-darwin-arm64 run -it ubuntu
Killed: 9

I uploaded a fresh set of diagnostics again. Thanks!
Diagnostics ID: E8B1A495-7656-487E-BCCE-922AE82AEA48/20210521211310

[djs55]

@uk-ar thanks for the feedback. I'm sorry the CLI build didn't work. I've got another experimental build, this time it's a full Docker Desktop install. If you'd like to try it the build is here: https://desktop-stage.docker.com/mac/stable/arm64/64865/Docker.dmg Unfortunately it hasn't been notarized so you will probably get a warning from macOS when you try to open it.

This build contains another experimental build of the Docker CLI:

% docker version
Client:
 Cloud integration: 1.0.16
 Version:           20.10.6-26-g2945ba4f7a

If you get a chance to try that build, let me know how it goes! If it still fails, could you upload a fresh set of diagnostics and quote the ID here? Thanks!

[uk-ar]

@djs55 Thank you for your support. I tried your build, but it still fails.

$ docker version
Client:
 Cloud integration: 1.0.16
 Version:           20.10.6-26-g2945ba4f7a
 API version:       1.41
 Go version:        go1.16.3
 Git commit:        2945ba4f7a
 Built:             Wed May 26 09:29:34 2021
 OS/Arch:           darwin/arm64
 Context:           default
 Experimental:      true

Server: Docker Engine - Community
 Engine:
  Version:          20.10.6
  API version:      1.41 (minimum version 1.12)
  Go version:       go1.13.15
  Git commit:       8728dd2
  Built:            Fri Apr  9 22:44:13 2021
  OS/Arch:          Linux/arm64
  Experimental:     false
 containerd:
  Version:          1.4.4
  GitCommit:        05f951a3781f4f2c1911b05e61c160e9c30eaa8e
 runc:
  Version:          1.0.0-rc93
  GitCommit:        12644e614e25b05da6fd08a38ffa0cfe1903fdec
 docker-init:
  Version:          0.19.0
  GitCommit:        de40ad0

$ docker run --init -it ubuntu
root@015a94723d5c:/# e%

This build works without --init option.

docker run -it ubuntu
root@bfb937e97d62:/# exit
exit

I uploaded a fresh set of diagnostics again. Thanks!
Diagnostics ID: E8B1A495-7656-487E-BCCE-922AE82AEA48/20210526202258

[djs55]

In the most recent diagnostic there is still an unexpected signal , this time a SIGIO:

time="2021-05-27T05:21:07+09:00" level=info msg="proxy << POST /v1.41/containers/a778a5d3e6116da00432494dfab8006c62b078e137340714561534af01b9f914/start (217.994084ms)\n"
time="2021-05-27T05:21:07+09:00" level=info msg="proxy >> POST /v1.41/containers/a778a5d3e6116da00432494dfab8006c62b078e137340714561534af01b9f914/resize?h=37&w=148\n"
time="2021-05-27T05:21:07+09:00" level=info msg="proxy << POST /v1.41/containers/a778a5d3e6116da00432494dfab8006c62b078e137340714561534af01b9f914/resize?h=37&w=148 (3.45025ms)\n"
time="2021-05-27T05:21:08+09:00" level=info msg="proxy >> POST /v1.41/containers/a778a5d3e6116da00432494dfab8006c62b078e137340714561534af01b9f914/kill?signal=IO\n"
time="2021-05-27T05:21:08+09:00" level=info msg="proxy << POST /v1.41/containers/a778a5d3e6116da00432494dfab8006c62b078e137340714561534af01b9f914/kill?signal=IO (37.859ms)\n"
time="2021-05-27T05:21:08+09:00" level=info msg="proxy >> POST /v1.41/containers/a778a5d3e6116da00432494dfab8006c62b078e137340714561534af01b9f914/kill?signal=IO\n"
time="2021-05-27T05:21:08+09:00" level=info msg="proxy << POST /v1.41/containers/a778a5d3e6116da00432494dfab8006c62b078e137340714561534af01b9f914/kill?signal=IO (74.45225ms)\n"

If I explicitly kill -IO <pid of docker run> then the signal is forwarded and the container exits. I don't know where the signal is coming from though.

@uk-ar are you using the default macOS Terminal application or something else?

[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