Docker compose logs with logging driver: none halts log output with error

[lvaneijden]

Description When using docker compose logs -f (V2) or docker-compose logs -f (V1) on my composed services with logging driver set to "none", it outputs some log lines follow by: Error response from daemon: configured logging driver does not support reading.

Steps to reproduce the issue:

1. Create a small docker-compose.yaml file (See for a subset of our services https://gist.github.com/lvaneijden/0397b2cc2cbac4bf9c6f828a27ae759e. Our actual docker-compose file contains about 30-40 services)
2. Start the services with docker compose up -d
3. After the services have started, type the command docker compose logs -f

Describe the results you received: lex.van.eijden@Lexs-MacBook-Pro test-compose % docker compose up -d [+] Running 8/8 ⠿ Network test-compose_default Created 0.0s ⠿ Container test-compose-memcached-1 Started 0.9s ⠿ Container test-compose-mongo-1 Started 1.1s ⠿ Container test-compose-local-smtp-catcher-1 Started 1.6s ⠿ Container test-compose-fake-s3-1 Started 1.3s ⠿ Container test-compose-mariadb-1 Started 1.6s ⠿ Container test-compose-redis-1 Started 1.2s ⠿ Container test-compose-mysql-1 Started 1.4s lex.van.eijden@Lexs-MacBook-Pro test-compose % docker compose logs -f Error response from daemon: configured logging driver does not support reading

Describe the results you expected: Expect to view the logging for any service that does not have logging driver: none set. Expected to not see any log lines for the services with logging driver: none set.

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

• When I start the services with docker compose up, without the -d flag to sent it to the background, the logging output is correct.
• I tried adjusting the logging driver to any other keyword: None and in quotes "none", neither gave a different result (This idea came from another issue I found: https://github.com/docker/compose/issues/8136)
• Adjusting the docker compose version from version 3 to 3.9 did nothing

Output of docker compose version:

lex.van.eijden@Lexs-MacBook-Pro test-compose % docker compose version
Docker Compose version v2.2.1

Output of docker info:

Client:
 Context:    default
 Debug Mode: false
 Plugins:
  buildx: Docker Buildx (Docker Inc., v0.7.1)
  compose: Docker Compose (Docker Inc., v2.2.1)
  scan: Docker Scan (Docker Inc., v0.11.0)

Server:
 Containers: 69
  Running: 0
  Paused: 0
  Stopped: 69
 Images: 202
 Server Version: 20.10.11
 Storage Driver: overlay2
  Backing Filesystem: extfs
  Supports d_type: true
  Native Overlay Diff: true
  userxattr: false
 Logging Driver: json-file
 Cgroup Driver: cgroupfs
 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: 7b11cfaabd73bb80907dd23182b9347b4245eb5d
 runc version: v1.0.2-0-g52b36a2
 init version: de40ad0
 Security Options:
  seccomp
   Profile: default
  cgroupns
 Kernel Version: 5.10.76-linuxkit
 Operating System: Docker Desktop
 OSType: linux
 Architecture: x86_64
 CPUs: 12
 Total Memory: 15.64GiB
 Name: docker-desktop
 ID: WHLT:KGQ6:RWD4:USIO:BGOI:Z3ON:BCOD:SHCQ:5LUM:UPNN:7K2A:FWJW
 Docker Root Dir: /var/lib/docker
 Debug Mode: false
 HTTP Proxy: http.docker.internal:3128
 HTTPS Proxy: http.docker.internal:3128
 Registry: https://index.docker.io/v1/
 Labels:
 Experimental: false
 Insecure Registries:
  127.0.0.0/8
 Live Restore Enabled: false

Additional environment details: On my macbook running docker for mac with docker-compose locally:

• Mac OS Big Sur version 11.6
• Docker for Mac 4.3.1 (72247). Other details: Engine: 20.10.11 Compose: 1.29.2 Credential Helper: 0.6.4 Kubernetes: v1.22.4 Snyk: v1.563.0

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

[KyleKing]

@stale, I'm pretty sure this bug is still present in latest

[stale[bot]]

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

[lvaneijden]

Bump, any new info from anybody else? We still have this problem over here...

[roniemartinez]

+1 This bug is still there

[lvaneijden]

New bump, still cannot grab logging from a running stack. Any way to upvote this or bring more attention to it?

[ndeloof]

Once you configure logging driver to none then docker engine won't store container logs ... obvioulsy And then this is expected you can't later retrieve logs (arguably, the engine error message is a bit cryptic)

The actual question is: why would you set logging driver to none?

Most users relied on this in the past to avoid logs from utility (and verbose) services so they can watch useful logs from application. An alternative exists using docker compose up --attach xxx so you only get logs from relevant services.

[lvaneijden]

@ndeloof That is the entire point, in a large compose file, I just want some services to not output anything (e.g. I got mailcatcher for example, that displays about 1500+ lines when it does its mail things), and others to perform their regular logging. The alternative of connecting with --attach sounds horrible, if you have 20+ services and don't want logging for 3, you then need to include the 17 into the attach statement. Perhaps there are other alternatives I've not yet discovered?

[ndeloof]

@lvaneijden ok makes sense. So

1. we should not fail when a service is configured with logging driver:none (show a warning)
2. introduce some --no-attach=xx (or a better noun? --silent=service?) so one can ignore a specific set of services

[lvaneijden]

🙏 Thank you for working on a solution, looking forward to the release with this fix