Unable to capture exec output to file or variable in bash

[gchamon]

Description

It used to be possible to just capture a docker-compose exec output and manipulate it later. Now even pipes in bash completely breaks because the command is not outputting to stdout anymore, and piping stderr to stdout doesn't work as a workaround.

Steps to reproduce the issue:

1. We need a persistent docker-compose.yml service, so I will just use nginx for this purpose:

version: "3"

services:
  nginx:
    image: nginx

2. docker-compose up -d nginx
3. Try to capture the output of an execution in the running container fails, for instance docker-compose exec nginx echo true | grep false will output true.

Describe the results you received:

It is impossible to capture the output of the command anymore. FOO=$(docker-compose exec nginx echo true) bash -c 'echo $FOO | grep false' will output true. For a sanity check, just run FOO=$(echo true) bash -c 'echo $FOO | grep false' and it outputs nothing.

Describe the results you expected:

To be able to capture docker-compose exec command output in a variable, use it in a pipe or redirect to a file.

Additional information you deem important (e.g. issue happens only occasionally):

Output of docker compose version:

Docker Compose version 2.2.3

Output of docker info:

Client:
 Context:    default
 Debug Mode: false
 Plugins:
  buildx: Docker Buildx (Docker Inc., v0.7.1-docker)
  compose: Docker Compose (Docker Inc., 2.2.3)

Server:
 Containers: 5
  Running: 4
  Paused: 0
  Stopped: 1
 Images: 54
 Server Version: 20.10.12
 Storage Driver: overlay2
  Backing Filesystem: extfs
  Supports d_type: true
  Native Overlay Diff: false
  userxattr: false
 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.runtime.v1.linux runc io.containerd.runc.v2
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: 1407cab509ff0d96baa4f0eb6ff9980270e6e620.m
 runc version: v1.0.3-0-gf46b6ba2
 init version: de40ad0
 Security Options:
  seccomp
   Profile: default
  cgroupns
 Kernel Version: 5.15.14-1-lts
 Operating System: Arch Linux
 OSType: linux
 Architecture: x86_64
 CPUs: 8
 Total Memory: 15.53GiB
 Name: chamon-anarchy
 ID: C6IX:KAHG:U45S:UDYA:G3OE:FO5M:ZCDK:PLCI:JKNO:XVD5:YTL3:3IGA
 Docker Root Dir: /var/lib/docker
 Debug Mode: false
 Registry: https://index.docker.io/v1/
 Labels:
 Experimental: false
 Insecure Registries:
  127.0.0.0/8
 Live Restore Enabled: false

Additional environment details:

[gchamon]

might be a symptom related to #7346, though I was expecting to at least be able to pipe stderr to stdout and have it captured, and it used to work not even a month ago

[gchamon]

Can confirm it works as expected on version 2.2.2. Downgraded it using pacman cache and docker-compose exec nginx echo true | grep true works as expected. This is a regression.

[ndeloof]

Tried to reproduce:

$ docker compose version
Docker Compose version v2.2.3
$ FOO=$(docker-compose exec nginx echo true)
$ echo $FOO
true
$ FOO=$(docker-compose exec nginx echo true) bash -c 'echo $FOO | grep false'
$ 

Did I missed something?

[gchamon]

Tried to reproduce:

$ docker compose version
Docker Compose version v2.2.3
$ FOO=$(docker-compose exec nginx echo true)
$ echo $FOO
true
$ FOO=$(docker-compose exec nginx echo true) bash -c 'echo $FOO | grep false'
$ 

Did I missed something?

That was supposed to reproduce the issue. Question is now why on my machine no matter what I did I was unable to capture exec output. Let me update docker-compose and try to reproduce again.

[gchamon]

Fascinating... what could be causing this? 2.2.2 is ok:

I will try to reproduce in virtual machines

[ndeloof]

ok, I can reproduce forcing use of compose as a CLI plugin:

$ FOO=$(docker compose exec nginx echo true)
true
$ echo $FOO

$

[ndeloof]

Works as expected if you force exec to disable TTY:

$ FOO=$(docker compose exec -T nginx echo true)
$ echo $FOO
true

relates to #9035
@ulyssessouza this is a place where auto-detection of an actual TTY made sense

[gchamon]

nice! thanks

I will just fix my automation pipelines by adding --no-TTY when capturing docker-compose exec output

[unrevised6419]

Worked for me

docker-compose exec --no-TTY ...

[keeth]

I'm here because my GitHub Actions CI tests, which do basically

docker compose run backend pytest

suddenly stopped printing any output when GitHub upgraded the build environment to Docker Compose 2.2.3.

docker compose run -T backend pytest fixed it ✨

[thomas-0816]

I'm also here because my Bitbucket Pipelines tests, which do basically

docker compose run ...

suddenly stopped printing any output when I upgraded the build environment to Docker Compose 2.3.3.

Docker Compose 2.2.2 does not have this issue with Bitbucket Pipelines.
Docker Compose 2.2.3 does have this issue with Bitbucket Pipelines.

[thomas-0816]

For me the issue got fixed by using Docker Compose 2.4.0.
For bitbucket pipelines, I had to set "export DOCKER_BUILDKIT=0" in order to avoid the build error message "listing workers for Build: failed to list workers: Unavailable: connection error: desc = "transport: Error while dialing unable to upgrade to h2c, received 403".