-
Notifications
You must be signed in to change notification settings - Fork 502
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
tini message are not flushed from stdout/stderr buffer until it die with the container #166
Comments
Interesting. Those logs actually go to stderr, not stdout, and they have trailing newlines, so even if stderr were line-buffered, flushing shouldn't be necessary. Any chance you have something like |
sorry for the delay for this answer, with a dockerfile configured with tini v0.19.0 : ls.sh is just a dummy bash script : ls exit 123 When I build and run the docker image, I get : The INFO text show after the the 'ls.sh' result. |
It's likely not tini's fault; stdout/stderr ordering is hard. Like this issue in Docker itself: |
Thanks. |
To set stdout and stderr as unbuffered, call |
@krallin Hi Thomas! You think it would be possible to switch stdout to line buffering? By default the stdout buffer in libc is around 4k whereas stderr is unbuffered by default. By the time I have tini "child segmentation fault" log output in the docker log, my main app (child process) already restarted and printed a ton of logging. Would be nice to see child segmentation fault log line right when it happened aligned with the log output of the main process and its error messages (tini prints "child exits with signal" to stdout - info/debug logging not stderr - which is fine, not all exits with a signal are abnormal - sigterm due to docker restart). Switching stdout to linebuffering won't hurt performance since tini barely does any logging even with -vv setlinebuf(stdout); the first line in main() |
@krallin As @igor-borovkov mentioned (thanks for digging out that info!), adding Should I open a PR? Out of curiosity, I did a bit of digging on my own, and found this interesting article about buffering, stating:
So Also, reading the glibc buffering docs, it looks like setvbuf(stdout, NULL, _IOLBF, BUFSIZ); |
Hello, maybe slightly unrelated but I wrote a blog post about different buffering approaches, in case you might find it interesting: https://blog.orhun.dev/stdout-vs-stderr/ |
the Spawned child process ... and Main child existed appears at the end of our container logs because they aren't flushed from stdout buffer.
after the fprintf \n, an fflush command need to be added to force the buffer to be flushed.
The text was updated successfully, but these errors were encountered: