Compose: The input device is not a TTY

[armpogart]

Following #5692 discussion, there is also some regression/bug concerning -T flag:

docker-compose exec service sh -c 'command`

works on:

$ docker-compose version
docker-compose version 1.18.0, build 8dd22a9
docker-py version: 2.7.0
CPython version: 2.7.14
OpenSSL version: LibreSSL 2.6.3

and older version (tested on 1.17.0, 1.17.1 and 1.18.0), but doesn't work on:

$ docker-compose version
docker-compose version 1.19.0, build 9e633ef
docker-py version: 2.7.0
CPython version: 2.7.14
OpenSSL version: LibreSSL 2.6.3

and gives following error:

$ docker-compose exec service sh -c 'command`
the input device is not a TTY

adding -T flag resolves the error.

[shin-]

You can probably work around this issue setting COMPOSE_INTERACTIVE_NO_CLI for the time being

Is command a specific command, or are you able to reproduce with simple commands as well (true, ls, etc)?

[armpogart]

@shin- It doesn't work with simple commands either (tried with ls).
Also COMPOSE_INTERACTIVE_NO_CLI doesn't help (see excerpt from my build):

$ env | grep COMPOSE_INTERACTIVE_NO_CLI
COMPOSE_INTERACTIVE_NO_CLI=0
$ docker-compose exec service sh -c 'ls'
the input device is not a TTY

But on second thought I don't even fully understand whether the previous behavior was right or not, because of this excerpt from docker-compose documentation (https://docs.docker.com/compose/reference/exec/):

Commands are by default allocating a TTY, so you can use a command such as docker-compose exec web sh to get an interactive prompt.

On the other hand, this is from man sh for -c flag:

Read commands from the command_string operand instead of from the standard input. Special parameter 0 will be set from the command_name operand and the positional parameters ($1, $2, etc.) set from the remaining argument operands.

So as far as I understand with -c flag I'm forcing to it not to use standard input and there is no need to allocate pseudo-tty (it must spawn non-login, non-interactive session of sh).
Anyways this is regression, it used to work, though I'm not sure again which behavior is the correct one.

P.S. As a reminder everything mentioned runs on CI, so there is no input device there.

[shin-]

@armpogart The workaround involves setting the variable to 1, not 0.

[armpogart]

@shin- oops, sorry)
Yeah, COMPOSE_INTERACTIVE_NO_CLI workaround is working.

[EugenMayer]

Same issue, solved the same way. Seems like this has been introduced in more recent docker-compose versions.

# this fixes the input device is not a TTY .. see https://github.com/docker/compose/issues/5696
export COMPOSE_INTERACTIVE_NO_CLI=1

What is the background here - is this actually a workaround or "by design"? Thanks

[devuo]

Is this ever going to be fixed?

[bscheshirwork]

for cron try to add environment from command line crontab -e like

COMPOSE_INTERACTIVE_NO_CLI=1
# Edit this file to introduce tasks to be run by cron.

https://stackoverflow.com/a/10657111/7670492

[tnguyen14]

I tried setting COMPOSE_INTERACTIVE_NO_CLI=1, and then I am getting this error instead:

16:07:56 [25291] Failed to execute script docker-compose
16:07:56 Traceback (most recent call last):
16:07:56   File "site-packages/dockerpty/pty.py", line 334, in start
16:07:56   File "site-packages/dockerpty/pty.py", line 367, in _hijack_tty
16:07:56   File "site-packages/dockerpty/io.py", line 59, in select
16:07:56   File "site-packages/dockerpty/io.py", line 351, in fileno
16:07:56   File "site-packages/dockerpty/io.py", line 103, in fileno
16:07:56   File "socket.py", line 635, in fileno
16:07:56 ValueError: I/O operation on closed file.
16:07:56 
16:07:56 During handling of the above exception, another exception occurred:
16:07:56 
16:07:56 Traceback (most recent call last):
16:07:56   File "bin/docker-compose", line 6, in <module>
16:07:56   File "compose/cli/main.py", line 71, in main
16:07:56   File "compose/cli/main.py", line 127, in perform_command
16:07:56   File "compose/cli/main.py", line 519, in exec_command
16:07:56   File "site-packages/dockerpty/pty.py", line 338, in start
16:07:56   File "site-packages/dockerpty/io.py", line 32, in set_blocking
16:07:56   File "site-packages/dockerpty/io.py", line 351, in fileno
16:07:56   File "site-packages/dockerpty/io.py", line 103, in fileno
16:07:56   File "socket.py", line 635, in fileno
16:07:56 ValueError: I/O operation on closed file.

This is when doing docker-compose exec ... on Jenkins pipeline.

docker-compose version on the Jenkins slave is 1.21.0.

[mhverbakel]

I was running a shell script from cron and I got the same error as @tnguyen14 (https://github.com/docker/compose/issues/5696#issuecomment-403605760).

I resolved my issue by running docker-compose exec -T ....

[speto]

@mhverbakel solution with -T flag (docker-compose exec -T) is a part of the first comment itself but I also in hurry hadn't read it carefully and messed with COMPOSE_INTERACTIVE_NO_CLI at first 😄
I use it in shell script executed from ant.

[ivnish]

Thanks!

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[armpogart]

@shin- Is this issue going to be closed without any fix by stale bot?
Maybe it is now the default behavior and you need documentation change?

[stale[bot]]

This issue has been automatically marked as not stale anymore due to the recent activity.

[ndeloof]

I tried to reproduce this issue :

#docker-compose.yaml
version: '3'
services:
    test:
        image: alpine
        command: sleep 1000

➜  docker-compose up -d
Creating foo_test_1 ... done
➜  docker-compose exec test sh 
/ # 

Tested on compose 1.24.1

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[armpogart]

Do I understand correctly that TTY is now allocated by default (https://docs.docker.com/compose/reference/exec/) and with need the flag or environment variable to disable pseudo-tty allocation. If I recall correctly the issue was opened as previously the default was the contrary behavior.

@ndeloof Where did you try to reproduce the issue? The issue was reproducible in CI environment where TTY can't be allocated usually (the details you can find in related issue from the original issue description).

[stale[bot]]

This issue has been automatically marked as not stale anymore due to the recent activity.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale[bot]]

This issue has been automatically closed because it had not recent activity during the stale period.

[tnguyen14]

I think this should be kept open, as I haven't seen any resolution.