log_driver=none + compose logs regression

[rtucek]

Description

docker compose logs [...] appends a Error response from daemon: configured logging driver does not support reading.

Steps to reproduce the issue:

1. It happens every time since pulled most recent updates from the distro (details see below).

Describe the results you received:

Container logs are still written to the CLI's output + the error message above is appended.

Describe the results you expected:

No errors :)

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

I use docker and docker-compose for my entire development setup, which has several docker-compose services. Since I work on several changes on these services in parallel, I usually have a terminal window with docker compose logs -f --tail 100 open to tail any application errors, debug logs, etc...

Since yesterday, after pulling Manjaro upgrades, docker (from 1:20.10.11-1 to 1:20.10.12-1) and docker-compose (from 2.2.2-1 to 2.2.3-2) got upgraded.

Since then, the docker compose logs always appends Error response from daemon: configured logging driver does not support reading at the end of the output. Specifically, this breaks the -f flag -> it doesn't "tail" the logs anymore, but rather aborts.

I don't have any specific daemon nor log config in place. I just use the default json-log file driver.

Note: docker logs [...] is not affected.

What I've tried so far prior opening this issue:

• searching for any similar reported issues, prior filling this issue (related to the most recent release)
• running docker run -it --rm --name test -p 80:80 nginx and tailing logs with docker logs -f test works fine
• Using docker logs -f docker_compose_service_name_or_container_id directly also works perfectly fine.
• docker compose logs [...] in various combinations (i.e. all containers, only 1 container, different flags)
• Checking with docker inspect -f '{{.LogPath}}' docker_compose_service_name_or_container_id if the file actually exists and content is written to it via sudo tail -f /var/lib/docker/containers/.../...-json.log -> yes that's the case.

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: 103
  Running: 7
  Paused: 0
  Stopped: 96
 Images: 215
 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.runc.v2 io.containerd.runtime.v1.linux runc
 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.10.93-1-MANJARO
 Operating System: Manjaro Linux
 OSType: linux
 Architecture: x86_64
 CPUs: 4
 Total Memory: 15.36GiB
 Name: dell-xps-9360
 ID: FSBZ:QC24:GZZZ:VFRF:NK7V:DE5V:TL3L:FZDS:3JHA:H7HC:QWIL:IPYM
 Docker Root Dir: /var/lib/docker
 Debug Mode: false
 Username: rtucek
 Registry: https://index.docker.io/v1/
 Labels:
 Experimental: false
 Insecure Registries:
  127.0.0.0/8
 Live Restore Enabled: false

Additional environment details:

none

[rtucek]

Ok, as it turns out, it's due to having this in my docker-compose.yml file:

[...]
  mailhog:
    image: mailhog/mailhog
    logging:
      driver: 'none'
    ports:
      - "8025:8025"
    profiles:
      - mailhog
[...]

Mind, that this mailhog service is not enabled by default, due to leveraging docker compose profiles, but apparently docker compose logs started complaining about it - even if the service is not active by default. Moreover, with the previous versions, this was just fine and even if if active, docker compose logs just worked as intended and ignore the service.

Kudos to @weissi1994 for bringing this to my attention.

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

[lephuongbg]

Not sure why this does not have more attention. Currently having to use both compose version (1 & 2) to workaround this regression.

TLDR for who would be triaging this issue: compose v2 currently fails immediately on docker compose logs -f, if one of the service has logging: {driver: none} config.

In contrast, compose v1's behavior is to ignore logging: {driver: none} services, and output logs for the others.

[stale[bot]]

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