[BUG] docker compose not respecting --progress quiet

[zorgoban]

Description

The docker compose command offers the option --progress quiet. Using that the output still contains the lines:
Attaching to <service name>
^MESC[<service-name> exited with code <return code>

I would expect docker compose to stay quiet.

Steps To Reproduce

For this specific case a loki cli service is defined

  loki-cli:
    container_name: grafana-loki-cli
    image: grafana/logcli:latest
    command: --addr=http://loki:3100 instant-query -q -o jsonl 'count_over_time({container_name="nginx"} | http_status >= 400 | json | keep remote_addr | remote_addr != ip("10.0.0.0/8") [7d]) > 3'
    depends_on:
      - loki
    networks:
      grafana-internal:
        ipv4_address: 10.4.0.6

The following shell comand is used to use the service to gather information

docker compose --ansi never --progress quiet up --no-log-prefix --quiet-build --quiet-pull --attach loki-cli >blacklist.tmp

The output file now contains the disturbing lines mentioned in the bug description.

Compose Version

Docker Compose version v5.0.2

Docker Environment

Client: Docker Engine - Community
 Version:    29.1.5
 Context:    default
 Debug Mode: false
 Plugins:
  buildx: Docker Buildx (Docker Inc.)
    Version:  v0.30.1
    Path:     /usr/libexec/docker/cli-plugins/docker-buildx
  compose: Docker Compose (Docker Inc.)
    Version:  v5.0.2
    Path:     /usr/libexec/docker/cli-plugins/docker-compose

Server:
 Containers: 38
  Running: 34
  Paused: 0
  Stopped: 4
 Images: 39
 Server Version: 29.1.5
 Storage Driver: overlayfs
  driver-type: io.containerd.snapshotter.v1
 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 splunk syslog
 CDI spec directories:
  /etc/cdi
  /var/run/cdi
 Swarm: inactive
 Runtimes: io.containerd.runc.v2 runc
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: dea7da592f5d1d2b7755e3a161be07f43fad8f75
 runc version: v1.3.4-0-gd6d73eb8
 init version: de40ad0
 Security Options:
  apparmor
  seccomp
   Profile: builtin
  cgroupns
 Kernel Version: 6.12.63+deb13-amd64
 Operating System: Debian GNU/Linux 13 (trixie)
 OSType: linux
 Architecture: x86_64
 CPUs: 16
 Total Memory: 15.4GiB
 Name: appsrv
 ID: 6b858894-ccbf-4c1d-86ec-853e8f62b722
 Docker Root Dir: /var/lib/docker
 Debug Mode: false
 Experimental: false
 Insecure Registries:
  ::1/128
  127.0.0.0/8
 Live Restore Enabled: false
 Firewall Backend: iptables

Anything else?

No response

[Pnkcaht]

Hi @ndeloof , sorry for the mention. I wanted to ask if it’s OK for me to work on this issue (or another one) in Compose.
I currently contribute mainly to Cagent and MCP, but I’d be happy to help here as well. Thanks :) 👍🏻

[ndeloof]

@Pnkcaht sure, please do

[ndeloof]

The docker compose command offers the option --progress quiet ... I would expect docker compose to stay quiet.

as the flag name suggest, this is about progress output, not all status messages.
What's the reason you want Compose not to display anything but container logs? Maybe you should use docker compose run

[zorgoban]

That's splitting hairs. I am using docker run right now. But that initializes a new container every run. As for why I only want compose to output the log should be pretty obvious from the example. The resulting file should only contain the requested data.

[ndeloof]

you can use docker compose run --rm to avoid an orphaned container

Closing as "not planned"

[zorgoban]

I know that and that's missing the point. If docker compose offers an option to stay quiet, it should stay quiet without any further exceptions. Also I was hoping to reduce startup time with docker compose up, since the existing container won't be newly initialized.

[ndeloof]

I was hoping to reduce startup time with docker compose up, since the existing container won't be newly initialized.

Container creation (once image is available in engine) is about milliseconds. Restarting an existing container won't give you a significant performance benefit