[BUG] Different behavior of shell scripts using docker-compose between file input and stdin

[sahib]

Description

I see different behavior in running a shell script from file and from stdin (see Steps to Reproduce).

Steps To Reproduce

The shell script is simple:

echo before
docker-compose exec -T redis echo hello
echo after

The docker-compose.yaml is simple too (and can be pretty much any container with echo binary):

---
version: "3.7"

services:
  redis:
    image: "redis:latest"
    command: redis-server

If run via file, the output is expected:

$ bash script.sh
before
hello
after

If run from stdin, the output stops after the compose command:

$ bash < script.sh
before
hello

Exit code is 0 and there seems to be no error. From a quick glance I saw no difference when executed with strace. The -T (--no-TTY) seems to be the culprit and it somehow seems to cause a close of bash's stdin.

This is probably not a bug in docker-compose, but that was the closest issue template available.
I only have been able to reproduce with docker-compose though, so I'm posting here in the hope that someone can explain.

Compose Version

Docker Compose version 2.16.0

Docker Environment

Client:
 Context:    default
 Debug Mode: false
 Plugins:
  buildx: Docker Buildx (Docker Inc.)
    Version:  v0.10.4
    Path:     /home/name/.docker/cli-plugins/docker-buildx
  compose: Docker Compose (Docker Inc.)
    Version:  2.16.0
    Path:     /usr/lib/docker/cli-plugins/docker-compose

Server:
 Containers: 12
  Running: 3
  Paused: 0
  Stopped: 9
 Images: 85
 Server Version: 23.0.1
 Storage Driver: btrfs
  Btrfs:
 Logging Driver: json-file
 Cgroup Driver: systemd
 Cgroup Version: 2
 Plugins:
  Volume: local
  Network: bridge host ipvlan macvlan null overlay
  Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog
 Swarm: inactive
 Runtimes: io.containerd.runc.v2 runc
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: 31aa4358a36870b21a992d3ad2bef29e1d693bec.m
 runc version:
 init version: de40ad0
 Security Options:
  apparmor
  seccomp
   Profile: builtin
  cgroupns
 Kernel Version: 5.15.94-1-MANJARO
 Operating System: Manjaro Linux
 OSType: linux
 Architecture: x86_64
 CPUs: 8
 Total Memory: 15.14GiB
 Name: werkzeug
 ID: PUZO:S6ZB:JI3Q:BBCI:X3UH:673F:HNHY:DOHB:CDMK:NBDN:W5J2:JUA3
 Docker Root Dir: /var/lib/docker
 Debug Mode: false
 Registry: https://index.docker.io/v1/
 Experimental: false
 Insecure Registries:
  127.0.0.0/8
 Live Restore Enabled: false

Anything else?

No response

[ndeloof]

I can confirm this is a docker compose bug: replacing command in script with docker exec xxx-redis-1 echo hello both ways to run with bash display the expected after string.

[ndeloof]

The root cause is that docker compose exec is configured to run in interactive mode by default. Doing so, the console stdout get closed after execution and no further message get displayed on screen.

Possible workaround is to run docker compose exec -T --interactive=false redis echo hello

[sahib]

I can confirm the workaround indeed works. 👍 I don't see --interactive in the help output though. Is it passed to docker exec or is it a hidden flag of docker compose exec? Still, quite a surprising behavior in total.

[ndeloof]

--interactive is indeed a hidden flag because it was created for parity with docker exec but not intended to be used for concrete use-cases as flag is enabled by default with docker compose.
Still surprising, I'm keeping this issue open so we investigate how we could better manage such a scenario

[sahib]

Maybe as a bit of background why piping to bash is useful: we have some migration and maintenance scripts (most of them contain some docker compose commands) that are triggered via ssh:

ssh user@host bash < migrate-blub.sh

Without we'd have to do something like that (not terrible, but annoying):

scp migrate-blub.sh user@host:/tmp/migrate-blub.sh
ssh user@host bash /tmp/migrate-blub.sh

(If it'd be a local use case without ssh, you could do bash <(cat migrate.blub.sh), but that obviously does not work over network boundaries)

[alspitz]

I'm seeing what seems like the same issue when using a docker compose inside of a timeout command. Vanilla docker exec works fine, but docker compose exec hangs, only if run in a timeout command and only if run in a non interactive bash process. This is on Docker compose v2.25.0. Passing --interactive=false after exec fixes it.

Is there a potential fix for this planned?

[ndeloof]

@alspitz No fix is planned for this issue, --interactive=true being the default behavior for years, changing this would be a significant breaking change. Using --interactive=false when used inside a script is the recommended workaround.

I'm closing this issue as "not planned"

[alspitz]

If there was any way to fail more gracefully, instead of just hanging, would be helpful too, without having to change the default behavior. Maybe a warning? I'm unfamiliar with the details so unclear if this is possible, but just throwing it out there. It took me an embarrassingly long time to figure out what was happening :D

[polarathene]

Using --interactive=false when used inside a script is the recommended workaround.

That should probably be documented, I was confused why docker compose exec lacked the option in it's docs.

There's --no-TTY (I would have expected all lowercase to be supported tbh 🤨) instead of --tty=false (which also seems to be supported/valid) , so if --no-interactive makes more sense for public documentation, perhaps go with that?

For a script in the container that I called a command for, it's use of read -p required -T -i=false. The defaults differing from the non-compose equivalent command is understandable, but opt-out is valid so the option should be documented?