Logging driver `none` seems to be ignored, CLI shows output.

[WeeJeWel]

Setting...

version: "3.8"
services:
  my_service:
    logging:
      driver: none

...still shows output to the console since docker-compose V2.

[KoditkarVedant]

@WeeJeWel There are two things I see here.

1. Settings logging driver to none which sets the logging driver in the docker container's HostConfig section. - which is set as expected by the docker compose. (I've tested it on v2.2.3)

2. What you are asking is a behavior where we should run a service in detached mode cause we set the logging driver to none. - which I what used to happen in the old version of docker compose.

Additional Information: To under stand how the docker run works. I executed below command

docker run --name test_nginx --log-driver none -p 8888:80 --rm nginx

which ran the container in foreground mode which shows the output of currently running service.

Now open the second terminal and the below command

docker container logs test_nginx

you will see no logs being returned from container. Which the expected behavior.

So I believe there is bit confusion between what logging-driver is and detached mode. I think this is because the way the legacy docker-compose CLI was implemented.

I just wanted to share this findings. I can not decide which behavior we should continue but In my opinion the behavior of docker-compose v2 is correct (not confusing).

Need your attention: @chris-crone @ndeloof @ulyssessouza

[ndeloof]

docker compose v1 indeed use the logging API, and doing so won't collect any log when driver is set to none. docker compose v2 attach to container (just like docker run does) and does not rely on the docker engine to collect logs with a driver.

IHMO relying on logging driver to exclude logs from the compose up output is just a hack, should not be considered a "feature" to be reproduced for backward compatibility. The ability to exclude logs from a few services is something to be considered as an explicit option.

[WeeJeWel]

Yeah, disabling logs for a specific service is a must-have imho. I’m really not interested in database logs, for example, they just pollute the console.

[KoditkarVedant]

I liked the idea of adding support to run specific service in detached mode. For example:

Currently we have option to run all services in detached mode

docker compose up -d 

Similarly we can also run only a service in detached mode using the below command

docker compose run -d service_name

Proposal: We can add property on Service to specify the detach option like

version: '3.4'
services:
  service1:
    image: alpine
    detach: true    # you can set if you would like to run this service in detach mode

  service2:
    image: alpine

Note: by default detach is false

Now when you run docker compose up it will run service1 in detach mode and service2 in foreground mode. If you run docker compose up -d it will override the detach options on each service.

In current CLI when you run services in foreground mode (attached mode) & on sending interrupt (terminate) signal SIGINT by pressing Ctrl + c it stops all containers but in suggested it will only stop attached containers you user needs to manually stop the container running in detached mode.

[ndeloof]

docker compose up --detach SERVICE unfortunately doesn't make it clear is SERVICE applies to the detach option or is set to select services to be started by up. I guess for clarity we need a new dedicated flag

I suggest we introduce: docker compose up --attach-to SERVICE ... docker compose up --detach-from SERVICE ... (--detach would then be somehow an alias for --detach-from *) wdyt?

[KoditkarVedant]

docker compose up --detach SERVICE should only override that for the specified services in command. I've just checked we have similar behavior for --attach flag. If you specify it only attaches to those services and rest of the services run in detached mode.

So we only need to add the a config detach. It will get overridden by two flags --attach --detach.

• If you specify SERVICE name (example in up, run) commands. It will override the detach setting on those services
• If not it will use the specified settings in config files
• If neither is specified (in command or config file) it will consider detach as false (existing behavior)

[ndeloof]

You're right about --attach flag, indeed offers this as a recently introduced flag (I forgot about this one, whenever I'm the one who introduced it, seems my brain sometime needs a cache refresh 😅 ).

We can't change the meaning of the boolean --detach flag without breaking backward compatibility, i.e. docker compose up --detach SERVICES used to start only SERVICES (and dependencies) in detached mode (for all of them). With suggested change, it would suddenly start all services in the compose file, and run a few of them in detached mode. So we need a distinct flag, like docker compose up --ignore SERVICE1 [SERVICES...] (or any other flag name, suggestions are welcome)

[KoditkarVedant]

I think I wasn't aware of the dependencies part. In that case also our change will also be backward compatible. I mean if you specify docker compose up --detach SERVICE it will override the config of Service and it's dependencies like it does it now. I believe we must be doing that for docker compose up --attach SERVICES right?

Is my understanding correct? what we are going to allow user is an ability to set these configs in the Yaml. if the override it via CLI it will override the way it does now (Service + it's dependencies).

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

[WeeJeWel]

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.

I’d still like a solution.

[stale[bot]]

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