php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Request #71880 Optionally disable warnings when writing to STDOUT
Submitted: 2016-03-22 14:29 UTC Modified: 2019-09-13 07:52 UTC
Votes:130
Avg. Score:4.5 ± 0.8
Reproduced:124 of 125 (99.2%)
Same Version:38 (30.6%)
Same OS:92 (74.2%)
From: haertl dot mike at gmail dot com Assigned: nikic (profile)
Status: Closed Package: FPM related
PHP Version: 5.6.19 OS: Linux
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: haertl dot mike at gmail dot com
New email:
PHP Version: OS:

 

 [2016-03-22 14:29 UTC] haertl dot mike at gmail dot com
Description:
------------
When you write to STDOUT PHP-FPM creates a warning.

This is a problem when you want to run PHP-FPM in a docker container. It's common pratice for docker containers to write any log output to STDOUT/STDERR.

If you do this with e.g. with the official php-fpm docker image, you'll end up with tons of ugly warnings like above. Right now there's no way to get rid of these warnings. It will also split up a single multi-line output into several distinct warnings.


Related issue at docker:
https://github.com/docker-library/php/issues/207



Test script:
---------------
$fp = @fopen('php://stdout','w');
fwrite($fp, "my output string...");

Expected result:
----------------
There should be an ini-Setting to turn off these warnings.

Actual result:
--------------
WARNING: [pool www] child 12 said into stdout: "my output string..."

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2016-07-06 09:28 UTC] copong at gmail dot com
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.
 [2016-07-06 11:01 UTC] inefedor at gmail dot com
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.
 [2016-08-25 16:42 UTC] mark dot sagikazar at gmail dot com
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.
 [2016-08-26 07:28 UTC] haertl dot mike at gmail dot com
> 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.
 [2016-08-26 07:49 UTC] mark dot sagikazar at gmail dot com
> 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.
 [2016-08-26 07:57 UTC] haertl dot mike at gmail dot com
> 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.
 [2016-08-26 08:05 UTC] mark dot sagikazar at gmail dot com
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.
 [2016-11-22 21:27 UTC] dvalentiate at gmail dot com
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.
 [2017-03-07 16:59 UTC] bugs dot php dot net at mog dot se
Hello.

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

Why is PHP mangling and truncating my log data!?!?!?!?!?
 [2017-03-07 17:10 UTC] bugs dot php dot net at mog dot se
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
 [2017-03-08 09:23 UTC] haertl dot mike at gmail dot com
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
 [2019-09-12 19:44 UTC] davi87 at protonmail dot com
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...
 [2019-09-12 19:54 UTC] nikic@php.net
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?
 [2019-09-13 06:06 UTC] haertl dot mike at gmail dot com
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.
 [2019-09-13 07:52 UTC] nikic@php.net
-Status: Open +Status: Closed -Assigned To: +Assigned To: nikic
 
PHP Copyright © 2001-2019 The PHP Group
All rights reserved.
Last updated: Thu Nov 21 16:01:21 2019 UTC