Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

exec does not set TERM env when -t passed #9299

Closed
lclarkmichalek opened this issue Nov 23, 2014 · 28 comments

Comments

@lclarkmichalek
Copy link

commented Nov 23, 2014

Passing -t to docker run will set the TERM environment variable. Doing so to docker exec will not. This causes things like htop to not work.

$ docker run -d --name foo debian bash -c "while true; sleep 1; done"
2fc4a0d2fc6d
$ docker exec -ti foo env
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
HOSTNAME=2fc4a0d2fc6d

Or a case that the end user is more likely to experience:

$ docker run -d --name foo debian bash -c "while true; sleep 1; done"
2fc4a0d2fc6d
$ docker exec foo "apt-get update && apt-get install -y htop"
....
$ docker exec -ti foo htop
Error opening terminal: unknown.

Versions and stuff:

$ docker version
Client version: 1.3.1
Client API version: 1.15
Go version (client): go1.3.3
Git commit (client): 4e9bbfa
OS/Arch (client): linux/amd64
Server version: 1.3.1
Server API version: 1.15
Go version (server): go1.3.3
Git commit (server): 4e9bbfa
$ uname -a 
Linux hostname 3.13.0-35-generic #62-Ubuntu SMP Fri Aug 15 01:58:42 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
$ docker -D info
Containers: 186
Images: 2828
Storage Driver: aufs
 Root Dir: /var/lib/docker/aufs
 Dirs: 3206
Execution Driver: native-0.2
Kernel Version: 3.13.0-35-generic
Operating System: Ubuntu 14.04.1 LTS
Debug mode (server): false
Debug mode (client): true
Fds: 135
Goroutines: 224
EventsListeners: 1
Init Path: /usr/bin/docker
WARNING: illegal base64 data at input byte 4
WARNING: No swap limit support

Apologies if this has already been reported/fixed (I didn't test against master, even though I know I should!)

@dqminh

This comment has been minimized.

Copy link
Contributor

commented Nov 24, 2014

@bluepeppers i think this is fixed in master.

@lclarkmichalek

This comment has been minimized.

Copy link
Author

commented Nov 24, 2014

I don't think so. Doing some more digging, this is actually a dupe of #8631, though I'm not sure I really accept the conclusion in that issue that this is expected behaviour. The primary use case of docker exec is debugging running containers, and I know I don't habitually run my containers with -t everywhere, making docker exec a whole lot less useful. It also contradicts the principle of least surprise, imo: I would expect the terminal to behave in the same way using docker run -t and docker exec -t.

@SvenDowideit

This comment has been minimized.

Copy link
Contributor

commented Nov 27, 2014

I'm tempted to agree with you - at bare minimum, if we do accept the assertion by @cpuguy83 and @jfrazelle , they should have added some documentation explaining it.

@tomfotherby

This comment has been minimized.

Copy link
Contributor

commented Dec 8, 2014

I got bitten by this issue. I finally got round to removing sshd from my containers now that all our servers have docker v1.3 and docker exec is available to do inspection and debugging. The problem is I do not run the main containers with -t and so when I get a shell into them with docker exec I have a dumb terminal

echo $TERM
dumb
less /etc/passwd
WARNING: terminal is not fully functional

I'm looking for a workaround. Doing reset doesn't seem to work:

reset
xterm
...
less /etc/passwd
WARNING: terminal is not fully functional

@yaronr

This comment has been minimized.

Copy link

commented Dec 19, 2014

workaround: use nsenter: https://github.com/jpetazzo/nsenter
It works

@angelrr7702

This comment has been minimized.

Copy link

commented Dec 21, 2014

maybe the documentation need to add -t to run command for all the use of of docker run and explain that is to make sure that docker exec work the correct way ...

@thaJeztah

This comment has been minimized.

Copy link
Member

commented Dec 21, 2014

+1. docker exec basically is for "exceptional" cases. Having to start a container with -t for exceptional cases doesn't seem logical to me.

@SvenDowideit SvenDowideit self-assigned this Dec 22, 2014

@Recodify

This comment has been minimized.

Copy link

commented Dec 31, 2014

Workaround:

  1. Enter container with docker exec.
  2. Run command: export TERM=xterm

I've tested this on a OSX host with boot2docker vm.

Note, this will not survive restarts.

@jessfraz

This comment has been minimized.

Copy link
Contributor

commented Feb 26, 2015

closing as dup of #8755

@dashohoxha

This comment has been minimized.

Copy link

commented Sep 3, 2015

Workaround:

docker exec -it $container /bin/bash -c "export TERM=xterm; exec bash"

Works very well.

@kramarama

This comment has been minimized.

Copy link

commented Sep 21, 2015

I find it easier to remember:

docker exec -ti test env TERM=xterm bash -l
@dashohoxha

This comment has been minimized.

Copy link

commented Sep 21, 2015

👍

1 similar comment
@cyril-bouthors

This comment has been minimized.

Copy link

commented Oct 22, 2015

👍

@peerasan

This comment has been minimized.

Copy link

commented Oct 28, 2015

kramarama is very to remember

@aidanhs

This comment has been minimized.

Copy link
Contributor

commented Oct 29, 2015

@jfrazelle this isn't a duplicate, can you reopen?

#8755 is about a nasty issue to do with invalid file descriptor symlinks and mounting devpts, more fully discussed at #11462.

This issue is about an environment variable (TERM) differing inside docker exec depending on whether you initially started the container with -t or not.

@cpuguy83 cpuguy83 reopened this Nov 3, 2015

oryband added a commit to kikinteractive/10M-Docker-Images that referenced this issue Nov 15, 2015
oryband added a commit to kikinteractive/10M-Docker-Images that referenced this issue Nov 15, 2015
remonlam added a commit to remonlam/docker-mysql that referenced this issue Dec 26, 2015
remonlam added a commit to containerstack/docker-wordpress that referenced this issue Dec 26, 2015
@bhdrk

This comment has been minimized.

Copy link

commented Jan 7, 2016

@samshiles's answer is worked for me.

@hervenicol

This comment has been minimized.

Copy link

commented Feb 23, 2016

Just encountered the same issue.
At least the doc could mention that "-t" has a slightly different effect with "run" and with "exec".

What is misleading is that:

  • both options have the same name (-t, --tty)
  • both options descriptions are the same (Allocate a pseudo-TTY)
@freman

This comment has been minimized.

Copy link

commented May 17, 2016

It would be nice if we could pass multiple environment variables (ala -e)

I confess we're seriously abusing the exec api to avoid giving ssh to people to do things they shouldn't be doing in a production environment - containers should be treated as immutable black boxes, if you can't diagnose from logs then you're doing logging wrong - all the arguments, I've had them.

@vipseixas

This comment has been minimized.

Copy link

commented May 20, 2016

@freman The production environment is the last step of a container workflow. Before you have your perfect black production box there's a lot of work you have to do with exec.

@freman

This comment has been minimized.

Copy link

commented May 20, 2016

@vipseixas we've been doing this for almost two years, it's literally "let the devs tinker with their php in production" type work (because face it, it's easier to syntax error 30 live instances of the site in docker than it is to work offline, test, etc), the rest of everything is stable. The problem is as the exec api stands it's not suitable for doing that at least not on a production machine. No tidy way to clean up after someone that just closes their terminal instead of exiting properly, no tidy way to pass env, probably more I'm forgetting after so little sleep. I have been trying to write a tool that lets us exec right into a shell the thing remotely (ala ssh but reverse proxied so there's no ports exposed, with full session recording, and easier to integrate auth) but these issues make it un-appealing

@typekpb

This comment has been minimized.

Copy link

commented Jun 24, 2016

any chance to get this one fixed, to make using docker exec more comfortable?

@grosser

This comment has been minimized.

Copy link

commented Sep 1, 2016

FYI terminal copy + cols/rows fix

kubectl exec -it $1 -- /bin/bash -c "stty rows $(tput lines) cols $(tput cols) && export TERM=$TERM && exec bash"

grosser/dotfiles@eca07c9

crosbymichael added a commit to crosbymichael/docker that referenced this issue Sep 9, 2016
Add TERM env var to exec
When the `-t` flag is passed on exec make sure to add the TERM env var
to mirror the expected configuration from run.

Fixes moby#9299

Signed-off-by: Michael Crosby <crosbymichael@gmail.com>
crosbymichael added a commit to crosbymichael/docker that referenced this issue Sep 12, 2016
Add TERM env var to exec
When the `-t` flag is passed on exec make sure to add the TERM env var
to mirror the expected configuration from run.

Fixes moby#9299

Signed-off-by: Michael Crosby <crosbymichael@gmail.com>

@LK4D4 LK4D4 closed this in #26461 Sep 12, 2016

@thaJeztah thaJeztah added this to the 1.13.0 milestone Sep 12, 2016

@thaJeztah

This comment has been minimized.

Copy link
Member

commented Sep 13, 2016

We just merged a pull-request that automatically sets TERM if docker exec is started with a tty (-t) #26461

This change will go into the next release (1.13)

opnfv-github pushed a commit to opnfv/fuel that referenced this issue Nov 3, 2016
ci, build/f_repos: Minor UX improvements
After Armband rework landed of top of `build/f_repos` mechanism [1],
the following minor UX improvements can also be applied to Fuel's
f_repos:
- set SHELL to "/bin/sh" (we don't use any bash-isms);
- improve "From SHA..." removal for exported patches;
- force checkout of root tag commit during clean;
- silence progress during git clone (cleaner logs);
- support git older than 1.8.4 in `make clean` (fix Armband deploy);

FIXME:
 Pass TERM as Docker env var until [2] is fixed in Docker 1.13.

v4 -> v5:
 * Moved `export TERM` to Releng, where it actually belongs [3];
 * Fixed Armband deploys fail [4] by adjusting `make clean`;

[1] https://gerrit.opnfv.org/gerrit/#/c/22791/
[2] moby/moby#9299
[3] https://gerrit.opnfv.org/gerrit/#/c/22933/
[4] https://build.opnfv.org/ci/view/armband/job/\
    fuel-deploy-armband-baremetal-daily-master/57/consoleText

Fixes: FUEL-200

Change-Id: I80e3074f8659769e21f5b56f07c34c7a5de727bc
Signed-off-by: Alexandru Avadanii <Alexandru.Avadanii@enea.com>
@bocharsky-bw

This comment has been minimized.

Copy link

commented Dec 6, 2016

@thaJeztah Thanks! What about docker-compose exec? I can't use -t option there...

@thaJeztah

This comment has been minimized.

Copy link
Member

commented Dec 6, 2016

@bocharsky-bw docker-compose should use the same API, but if it's not working with the 1.13 daemon, it's best to open an issue in the docker-compose issue tracker; https://github.com/docker/compose/issues

@tianon tianon referenced this issue Apr 5, 2017
@itbj

This comment has been minimized.

Copy link

commented Apr 6, 2017

我今天也遇到这个问题,估计是TERM的问题。谢谢。

@thaJeztah

This comment has been minimized.

Copy link
Member

commented Apr 6, 2017

Google translate;

I have encountered this problem today, it is estimated that the problem of TERM. Thank you.

@dasgoll

This comment has been minimized.

Copy link

commented Mar 20, 2018

Works like a charm
kubectl exec -it kafka-kafka-0 -- bash -c "export TERM=xterm; exec bash"
or
kubectl exec -it kafka-kafka-0 -- bash -c "export TERM=xterm; bash"
docker exec -it $container /bin/bash -c "export TERM=xterm; exec bash"

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
You can’t perform that action at this time.