A feature-flag service's Python print() startup logs never reach the log collector when its container is killed 45 seconds into a cold start — what is happening, and what do you change?

## Why a container changes the behaviour at all Nothing about the code changed between the developer's laptop and the platform — what changed is what file descriptor 1 is attached to. Locally it is a terminal, so CPython gives `sys.stdout` line buffering at interpreter startup and every `print()` is visible instantly. Under a container runtime, stdout is a pipe read by the log collector. That is not a terminal, so the same interpreter chooses **block buffering**, and output accumulates in the process's own memory until the block fills, something flushes it, or the interpreter finalizes. A cold start emits very little text — a handful of breadcrumbs about configuration, connections and cache warm-up. That is nowhere near the block size, so *none* of it leaves the process during those 45 seconds. ## Two failure shapes, one cause **Hard kill.** When the platform's startup deadline expires it kills the container. Interpreter finalization never runs, so the buffered text is never handed to the kernel and is simply gone. From the collector's point of view the service produced no logs at all before dying, which is the most misleading possible signal: it makes the process look hung before it printed anything, when in fact it printed plenty. **Clean exit.** Suppose the real defect is a circular import that raises at startup. Now the interpreter *does* finalize: it prints the traceback to `sys.stderr`, which is line-buffered even when redirected (Python 3.9 changed this; before, redirected stderr was fully buffered), so those lines arrive immediately. The stdout breadcrumbs are flushed later, during shutdown, in a single blob. A collector that merges both streams by arrival time now shows the failure first and the steps leading up to it afterwards. Engineers read that ordering literally and chase the wrong subsystem. That asymmetry is also the diagnostic tell: *stderr arrives, stdout does not* means buffering, not a broken logging path. ## The fix, and why it belongs in the environment `PYTHONUNBUFFERED=1` set in the image's environment forces both standard streams unbuffered for every process the image starts. Preferring the environment variable over `-u` on the command line matters in practice, because entrypoints are frequently a shell wrapper, a supervisor or a process manager that re-invokes the interpreter; a variable is inherited through all of that, while a flag lives on exactly one command line. `-u` is the equivalent when you do own the invocation. Neither has any effect on stdin. Since Python 3.7 the unbuffered setting reaches the text layer too, so `sys.stdout.write_through` becomes `True` and `line_buffering` reads `False` — every write goes straight down. ## The alternatives, and their limits * **`sys.stdout.reconfigure(line_buffering=True)`** as the first statement of the entrypoint. Cheaper than fully unbuffered — one syscall per line rather than per write — but it runs *after* the imports at the top of that module, so anything printed by an import that fails is still governed by the original policy. For a startup bug specifically, that is the wrong side of the problem. * **`print(..., flush=True)` everywhere.** It works and it does not scale: it is a per-call decision spread across the codebase, and one forgotten call is one lost breadcrumb, in the exact code path you were trying to observe. * **Route diagnostics to `sys.stderr`.** Reasonable in its own right — stderr's line buffering makes it the low-latency stream — but it does not fix stdout for whatever still writes there. ## What unbuffering costs One `write` syscall per write call. For startup breadcrumbs and ordinary service logging that is invisible. For a process emitting a high-rate stream of short lines it is measurable, and line buffering is then the better setting: it bounds latency to one line while still coalescing partial writes. Bulk data being piped onward should keep the block buffer entirely. ## Closing the loop on the incident Once the output survives, the 45-second cold start becomes debuggable: the breadcrumbs show where the time goes and whether the deadline is too tight or the startup work is too slow. Worth checking at the same time: whether anything in the startup path calls `os._exit()` or installs a signal handler that exits without letting finalization run — both skip the flush even when you have not been hard-killed — and whether a native extension writes to the descriptor directly, in which case its output is ordered by its own buffering, not Python's.