Compose: Option to log to stdout instead of stderr

Created on 11 Jul 2018  路  8Comments  路  Source: docker/compose

Feature request

It seems that informational messages are printed to stderr by design based on this comment:

docker-compose prints informational messages to stderr, and container output to the same stream as it was written to in the container (stdout or stderr).

I can see why this is the case as it separates informational messages from other output that could conceivably be piped to other commands. Including informational messages in stdout in this case would break the input-output flow.

I would like to be able to add a flag to get informational messages (log level INFO and below) to go to stdout instead so that I can leave stderr for warnings and errors only. I do not want to redirect all of stderr to stdout and I do not want to set the log level to WARNING and miss out on the informational messages.

The specific use case I have is when running docker-compose from within sbt, sbt will redirect the output from the docker-compose process to its logs (and output) and anything that comes from stderr will be prefixed with [error] (in red). I still want to see the informational messages but just not have them treated as errors.

stale

All 8 comments

Is this issue specific to docker-compose logging, or from the containers launched by d-c? We're seeing INFO logs going to stderr when we launch containers via Nomad and curious if we might be hitting the same issue as this; which would point to it being a deeper docker engine issue and not just d-c.

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.

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

we're facing the same issue integrating a build process with azure pipelines. Has anyone found any fix for this?

this is the only previous reference I've been able to found #2115

I'm dealing with this issue in a deployment process with Azure Pipelines and also had read it before in #2115.

I'm trying to launch Docker Compose commands remotely and I find that INFO level logs like "Creating service _myServ_" are printed to stderr and so detected as errors that make my pipeline fail.

Any solution or option to redirect WARNING level logs or below to stdout and get only the actual errors from stderr?

Had the same problem, see the solution here: #6482
In short:

  • docker-compose outputs to stderr AND stdout, so something like this should help:

docker-compose up -d $containerName 2>/dev/null

  • stderr is just another channel (that seems to be on purpose)
  • After docker-compose you should check the exit-code instead of checking error-messages in some log, that's more reliable

Features requests shouldn't be closed just because the lack of response by the authors...

The bug is still there, debug messages printed to stderr breaking developers everywhere. I recommend you to consider to use a configurable logging parameter if you want people to be able to ignore debug messages. stderror should be for errors, otherwise the name would be stdinfo.

This is affecting PowerShell scripts because under some scenarios (when ErrorActionPreference is Stop), any write to stderr will make the script to stop and throw an exception. That's the case when running some CI like Azure DevOps and that's why we need to make sure in every call to DockerCompose in our build system is wrapped changing that variable... I think this behavior of Docker Compose is really confusing.

I've just faced the same issue. It's expected behavior for any Linux program to make distinction between stdout and stderr.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

squeaky-pl picture squeaky-pl  路  3Comments

Hendrik-H picture Hendrik-H  路  3Comments

saulshanabrook picture saulshanabrook  路  3Comments

29e7e280-0d1c-4bba-98fe-f7cd3ca7500a picture 29e7e280-0d1c-4bba-98fe-f7cd3ca7500a  路  3Comments

bitver picture bitver  路  3Comments