Compose: Run command writes to stderr while should not.

[bolshakov]

I have a simple docker-compose file

version: '3'

services:
  postgres:
    image: postgres
    restart: always
  backup:
    image: postgres-backup
    depends_on:
      - postgres

When I run the backup service and suppress its output, it still writes not error messages to stdout:

✗ docker-compose -f docker-compose.yml run backup > /dev/null
Starting test_postgres_1 ...
Starting test_postgres_1 ... done

This is not expected behavior since Starting test_postgres_1 message does not look like an error. I understand the motivation of writing docker compose messages not to stdout. But I expect that stderr contains errors. For example, when I run backup using cron, I want to suppress stdout and receive error messages via email. But currently, I receive "Starting test_postgres_1" which obviously is not error messages.

It would be very helpful to have control over docker compose output while automating things.

[shin-]

What does or does not belong on stderr seems a bit subjective to me. In the case of docker run specifically, the assumption is that you need to receive your container's output on stdout and probably shouldn't get Compose's status messages mixed in.

Checking the command's exit code is probably a much better way to detect whether an error occurred.

[bolshakov]

I understand the demand to separate docker messages from application messages. Moving docker messages into stderr is a good trade off.

While docker output is useful while debugging, in production environment it may be desirable to have only application output. From this point of view separating docker output from application output is useful feature.

Having docker and application outputs mixed makes thinks harder.

[bolshakov]

if someone suffer while running docker compose in cron, there is an excellent tool for this called chronic from moreutils package. It runs a command quietly unless it fails.

For example, instead of

> docker-compose -f docker-compose.yml run backup > /dev/null
Starting test_postgres_1 ...
Starting test_postgres_1 ... done

you can write

> chronic docker-compose -f docker-compose.yml run backup

and it'll suppress output if exit code is zero.

[shin-]

The recently added --log-level option should mitigate this issue as well.

[ozkar99]

whats the appropiate log level for this?
even with --log-level CRITICAL

i still get output on stderr (which is not an error)

or is there any work-around to stop docker-compose writing to stderr things are not errors?

currently doing 2>&1 to redirect stderr to stdout but then i cant see actual errors on stderr.

[dragetd]

Could you elaborate on how this actually helps @shin- and eventually consider not simply closing the issue as long as it is not really confirmed that it is solved or a suitable workaround was found?

[rjlasko]

I agree that this is still an issue. Changing the log level does nothing to address writing output to STDERR when doing something like:

docker-compose --log-level=ERROR --no-ansi --file ~/docker-compose.yml run --rm my_service

I run this in cron and utilize cronic (which is highly regarded in the linux world) to send emails when actual errors occur. This is my crontab:

@hourly cronic docker-compose --log-level=ERROR --no-ansi --file ~/docker-compose.yml run --rm my_service

The log level does nothing for me, so i get the following in my emails:

Cronic detected failure or error output for the command:
docker-compose --log-level=ERROR --no-ansi --file ~/docker-compose.yml run --rm my_service

RESULT CODE: 0

ERROR OUTPUT:
Creating test_my_service_run ... 
Creating test_my_service_run ... done

STANDARD OUTPUT: