moby: Docker tty is not a tty with docker exec

I have a workaround :

docker exec -ti `your_container_id` script -q -c "/bin/bash" /dev/null

Ok, it’s an ugly one, but with it you can use tmux when you use docker exec

@ninrod No, because it’s too late for the changes to be merged into 1.13 (the RCs have already been released). I would expect it will be fixed in 1.14 (when Docker starts using the newer version of runC).

zacharys-pro:dev razic$ docker run --rm -t -d ubuntu bash
83c292c8e2d13d1b1a8b34680f3fb95c2b2b3fef71d4ce2b6e12c954ae50965a
zacharys-pro:dev razic$ Docker ps
CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS              PORTS               NAMES
83c292c8e2d1        ubuntu              "bash"              2 seconds ago       Up 1 second                             xenodochial_bardeen
zacharys-pro:dev razic$ docker exec -ti xenodochial_bardeen tty
/dev/pts/1
zacharys-pro:dev razic$ docker version
Client:
 Version:      17.06.0-ce
 API version:  1.30
 Go version:   go1.8.3
 Git commit:   02c1d87
 Built:        Fri Jun 23 21:31:53 2017
 OS/Arch:      darwin/amd64

Server:
 Version:      17.06.0-ce
 API version:  1.30 (minimum version 1.12)
 Go version:   go1.8.3
 Git commit:   02c1d87
 Built:        Fri Jun 23 21:51:55 2017
 OS/Arch:      linux/amd64
 Experimental: true

Great work everyone. Thank you very much.

opencontainers/runc#1018 has been merged. This can be closed as soon as Docker vendors the latest commit of runc.

With a container based on debian:8.6, to get both color support (e.g. for ls) and tmux working I had to use:

docker exec -it my-container env TERM=xterm script -q -c "/bin/bash" /dev/null

Fixed by #33007

@fernandoacorreia in docker 1.13, when you add -t, it will automatically set TERM=xterm see https://github.com/docker/docker/pull/26461

And there was much rejoicing.

@cpuguy83 when working in “dev mode” with my containers, I generally pass -it to docker run and fire up tmux (i.e. when it seems useful to me to do so). It would be extremely useful (to me) to be able to fire up tmux in the context of exec -it, regardless of whether -it had been passed to run. At present, since the environment provided by exec is not a tty – even when invoked with -it flags (a pseudo-TTY is not actually allocated, apparently) – it’s not possible to use it in this way. At the very least, perhaps the --help output of exec ought to be amended to indicate that its -it mode has limitations relative to run -it.

In other words, if this is a bug, it seems like it should be fixed. If it can’t be fixed at present, or if it’s a foreseen and/or intended limitation of exec, then an indication should be provided in the output of --help.

This will be in 17.06

I spent a couple hours on this last night, mostly to get over the learning curve. I think I understand the majority of what I need to complete this. Most of the work is actually already done, and @crosbymichael has graciously offered to provide guidance as necessary. I’ll give another update later tonight.

@ninrod i cannot guarantee anything but we will try

@imamassi script will also work. The fix exists within runc (opencontainers/runc#1018) but because it’s quite a large change it’s not been merged yet. We’re hoping to get it merged by the end of the month (in time for OCI 1.0-rc2).

This should be fixed with opencontainers/runc#1018

Sent from my iPhone

On Sep 9, 2016, at 6:05 PM, Arnaud Porterie notifications@github.com wrote:

Cc @crosbymichael!

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

Quoting @brauner from lxc/lxc#554 “This is a known bug in glibc and @hallyn has send a fix to glibc (https://sourceware.org/ml/libc-alpha/2016-08/msg00307.html). It just needs to be applied.”

Serge’s fix is surprising and elegant.

The version is YY.MM, and we target first week of the month, so first week of June, with release candidates before that

Quick update… I was able to get a container running via ctr, so I think I may have gotten over that hump. I’ve been learning a lot about how the whole thing works (containerd-shim etc). I think I now have everything I need to be able to test my changes once I implement them. Will provide another update soon.

Ok so a quick update; I think I can get this finished in a few days…

At this point I have my development environment up and running, such that I can iterate on the containerd codebase.

However, I’ve become stuck; I’ll ping @crosbymichael tomorrow for help, but I can’t seem to start an OCI bundle that was created via runc spec with ctr containers start… and I need to be able to use ctr containers exec to test my changes.

I’m using the docs here https://github.com/docker/containerd/blob/v0.2.x/docs/bundle.md to create the OCI bundle. I’m able to run the bundle using runc start (version v0.0.9), but as mentioned when trying to start the container using ctr, I get the following error:

$ ctr containers start redis $PWD
[ctr] rpc error: code = 2 desc = shim error: context deadline exceeded

Once I get this working, dropping in the changes should be as simple as consuming the https://github.com/crosbymichael/go-runc bindings that already support the new console functionality.

hi @cyphar, little lost here. So will this be fixed in docker 1.13?

The underlying issue is that we allocate a PTY outside the container’s mount namespace (so the PTY devices aren’t inside the container’s /dev partition), so the pseudomagical /proc/self/fd/{0,1,2} symlinks are “broken”. This breaks the way that things like su check if it’s being run in a TTY –stat(ttyname(0)) or similar.

Unfortunately I run coreos and running tmux on the host is not desirable, because I don’t want to modify the host image at all, just run docker images for everything. This bug impedes that.

On 18 March 2015 22:17:15 GMT+00:00, dbabits notifications@github.com wrote:

This is what I do now: run tmux on the docker host, not inside docker, and docker session in one of tmux’s windows. this achieves my goal explained above.

---

Reply to this email directly or view it on GitHub: https://github.com/docker/docker/issues/8755#issuecomment-83205365

Sent from my Android device with K-9 Mail. Please excuse my brevity.