Ensure that all the output on bootstrap goes to stderr #180
Conversation
|
Note that this PR has been created as draft because, for some reason, the added tests aren't passing @ GHA (they work perfectly here). I've to investigate that, but created the PR already so you can get an idea about the proposal. As commented above, the only alternative to this proposal is to, completely, remove all that output/echos. Ciao :-) |
That way we can filter out it if needed, for example if we just want to instantiate a php container to run a php script, we don't want all the bootstrap (entrypoint, ini config...) information to pollute the execution. That way, this will work as expected: ``` $ docker run --rm moodlehq/moodle-php-apache php -r 'echo "Hi!" . PHP_EOL;' 2>/dev/null Hi! ``` And, without discarding stderr, we still get all the information (stdout + stderr): ``` $ docker run --rm moodlehq/moodle-php-apache php -r 'echo "Hi!" . PHP_EOL;' Running PHP Configuration fetcher Checking for php configuration in environment Running entrypoint files from /docker-entrypoint.d/* Starting docker-php-entrypoint with php -r echo "Hi!" . PHP_EOL; Hi! ``` The only alternative to the above that I can imagine is to completely suppress any output (to both stdout and stderr) in out bootstrap. Note that I've also tried to send the information to Apache error log, but that was futile, because the images have error.log as alias of stderr.
stronk7
force-pushed
the
bootstrap_goes_to_stderr
branch
from
5e8c4b0 to
97474d4
Compare
|
Making the PR ready for review. It took some good time and debugging to me to understand why it was failing, the reason was that I was not mounting the fixtures directory in the 2 new |
|
(once/if this gets merged, I'll backport to all the branches supporting entry-points and php-ini...) |
|
Was going to ask if oyu think it's worth making it echo based on a DEBUG env var? |
Not really convinced here, mainly because all that information, now being sent to stderr is also available in the container logs (because the images error.log <==> stderr). So if anybody want to redirect stderr to /dev/null, to avoid it polluting output... that very same stderr still will be available via So, no convinced. Not sure how many people is using the container that way... |
That way we can filter out it if needed, for example if we just want to instantiate a php container to run a php script, we don't want all the bootstrap (entrypoint, ini config...) information to pollute the execution. That way, this will work as expected:
And, without discarding stderr, we still get all the information (stdout + stderr):
The only alternative to the above that I can imagine is to completely suppress any output (to both stdout and stderr) in out bootstrap.
Note that I've also tried to send the information to Apache error log, but that was futile, because the images have error.log as alias of stderr.