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

Projects
None yet
@lclarkmichalek

lclarkmichalek 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.

Show comment
Hide comment
@dqminh

dqminh Nov 24, 2014

Contributor

@bluepeppers i think this is fixed in master.

Contributor

dqminh commented Nov 24, 2014

@bluepeppers i think this is fixed in master.

@lclarkmichalek

This comment has been minimized.

Show comment
Hide comment
@lclarkmichalek

lclarkmichalek 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.

lclarkmichalek 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.

Show comment
Hide comment
@SvenDowideit

SvenDowideit Nov 27, 2014

Contributor

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.

Contributor

SvenDowideit 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.

Show comment
Hide comment
@tomfotherby

tomfotherby Dec 8, 2014

Contributor

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

Contributor

tomfotherby 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.

Show comment
Hide comment
@yaronr

yaronr Dec 19, 2014

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

yaronr commented Dec 19, 2014

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

@angelrr7702

This comment has been minimized.

Show comment
Hide comment
@angelrr7702

angelrr7702 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 ...

angelrr7702 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.

Show comment
Hide comment
@thaJeztah

thaJeztah Dec 21, 2014

Member

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

Member

thaJeztah 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.

Show comment
Hide comment
@Recodify

Recodify 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.

Recodify 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.

Show comment
Hide comment
@jessfraz

jessfraz Feb 26, 2015

Contributor

closing as dup of #8755

Contributor

jessfraz commented Feb 26, 2015

closing as dup of #8755

@dashohoxha

This comment has been minimized.

Show comment
Hide comment
@dashohoxha

dashohoxha Sep 3, 2015

Workaround:

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

Works very well.

dashohoxha 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.

Show comment
Hide comment
@kramarama

kramarama Sep 21, 2015

I find it easier to remember:

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

kramarama 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.

Show comment
Hide comment
@dashohoxha

dashohoxha commented Sep 21, 2015

👍

@cyril-bouthors

This comment has been minimized.

Show comment
Hide comment
@cyril-bouthors

cyril-bouthors commented Oct 22, 2015

👍

@peerasan

This comment has been minimized.

Show comment
Hide comment
@peerasan

peerasan Oct 28, 2015

kramarama is very to remember

peerasan commented Oct 28, 2015

kramarama is very to remember

@aidanhs

This comment has been minimized.

Show comment
Hide comment
@aidanhs

aidanhs Oct 29, 2015

Contributor

@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.

Contributor

aidanhs 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.

Show comment
Hide comment
@bhdrk

bhdrk Jan 7, 2016

@samshiles's answer is worked for me.

bhdrk commented Jan 7, 2016

@samshiles's answer is worked for me.

@hervenicol

This comment has been minimized.

Show comment
Hide comment
@hervenicol

hervenicol 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)

hervenicol 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.

Show comment
Hide comment
@freman

freman 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.

freman 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.

Show comment
Hide comment
@vipseixas

vipseixas 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.

vipseixas 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.

Show comment
Hide comment
@freman

freman 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

freman 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.

Show comment
Hide comment
@typekpb

typekpb Jun 24, 2016

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

typekpb commented Jun 24, 2016

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

@grosser

This comment has been minimized.

Show comment
Hide comment
@grosser

grosser 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

grosser 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.

Show comment
Hide comment
@thaJeztah

thaJeztah Sep 13, 2016

Member

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)

Member

thaJeztah 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.

Show comment
Hide comment
@bocharsky-bw

bocharsky-bw Dec 6, 2016

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

bocharsky-bw commented Dec 6, 2016

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

@thaJeztah

This comment has been minimized.

Show comment
Hide comment
@thaJeztah

thaJeztah Dec 6, 2016

Member

@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

Member

thaJeztah 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

Closed

Update Dockerfile #54

@itbj

This comment has been minimized.

Show comment
Hide comment
@itbj

itbj Apr 6, 2017

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

itbj commented Apr 6, 2017

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

@thaJeztah

This comment has been minimized.

Show comment
Hide comment
@thaJeztah

thaJeztah Apr 6, 2017

Member

Google translate;

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

Member

thaJeztah 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.

Show comment
Hide comment
@dasgoll

dasgoll 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"

dasgoll 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