Definitely an issue when running fpm on containers, only way we've found around this that doesn't involve tailing a log file is to pipe fpm's output through sed, which is hacky.

Just as a quick solution without the need for grepping/sedding you could use named pipes:

mkfifo /tmp/stdout

In docker CMD you'd write something along the lines of

CMD service start && tail -f /tmp/stdout

And in PHP you would need to write to /tmp/stdout, this way you won't have to use file system to store the output.

What's the advantage of using a named pipe instead of a file? The log file should be lost with the restart of the container anyway.

> What's the advantage of using a named pipe instead of a file? The log file should be lost with the restart of the container anyway.

Because that's how logging is handled in the docker world. There are many tools that you can use to dynamically route your logs to different targets, e.g. logspout. PHP-FPM can't be used in this way due to the issue above.

Logging to a file is not an alternative. You also don't want to lose your logfiles when a container is recreated.

> Logging to a file is not an alternative. You also don't want to lose your logfiles when a container is recreated.

I think you misunderstood me. I meant the tailing solution with a log file instead a named pipe.

> I meant the tailing solution with a log file instead a named pipe.

Because then you have to override the CMD in your Dockerfile. So whenever the CMD in the underlying official base image changes you must make sure, that you change your line accordingly. This is error prone as it's easy to miss this step whenever you upgrade to a newer version.

Okay, I still think there is a misunderstanding. I KNOW that we should log to stdout. BUT because of this bug it is not really developer friendly, SO there is a quick dirty hack:

> CMD service start && tail -f /tmp/stdout

This hack suggested using named pipes and I asked why not use a file instead, which might be the default for applications.

Of course, when this bug is resolved or someone doesn't care about it, we should use stdout.

To makes the php-fpm error logging not crappy I ended up putting

    mkfifo /tmp/stdout && chmod 777 /tmp/stdout

in my a run statement in my Dockerfile, and also setting

    error_log = /tmp/stdout
    access.log = /tmp/stdout

in a php config `.ini` file and 

    php-fpm | tail -f /tmp/stdout

in my docker-compose command call.

The result is clean PHP error logging.

Hello.

Neither named pipes or files are good alternatives to stdout when using Docker.

Why is PHP mangling and truncating my log data!?!?!?!?!?

As all commenters have concluded php://stdout is broken in php-fpm and I will work around by writing files outside the container directly using volume mounts

There's now also this PR which should solve the issue:

https://github.com/php/php-src/pull/1076

Related PHP bug: 

https://bugs.php.net/bug.php?id=69031

How come we are in 2019 and this warning message problem can't be turned off?

If 'catch_workers_output' is used to aggregate logs, isn't there a way to add 'workers_output_are_fine_and_totally_intended'?

Just saying, paradigm shifts... Containers were invented, PHP doing well and lots of people would benefit from keeping their logs as simples as possible...

Unless I'm misunderstanding something, isn't this what the decorate_workers_output option added in 7.3 does? Possibly this issue can be closed now?

I confirm: Since 7.3 you can set 'decorate_workers_output = no' in your php.ini wich fixes the problem.

The issue can be closed.