How does GODEBUG=inittrace=1 explain seconds of dead time before a Go program's first log line?

## The gap the tool exists to fill A Go program's start-up has a phase your instrumentation cannot see. Package-level variables are initialised and every `init` function runs before `main` is called, in an order the linker computes from the import graph: dependencies first, then the packages that import them. If that phase takes eight seconds, the application's first log line appears eight seconds late, no application log records why, and a CPU profile started at the top of `main` begins after the cost has already been paid. From the outside it looks like the process hung. `GODEBUG=inittrace=1` is the runtime's answer. Set it in the environment at launch — no rebuild, no code change — and the runtime prints one line on standard error for each package that has init work. ## Reading a line The format is: ``` init <package path> @<offset> ms, <clock> ms clock, <bytes> bytes, <allocs> allocs ``` - **package path** — the package whose init work this line describes. - **@offset ms** — how long after process start that package's init began. Reading the offsets down the list tells you where in the sequence the time went. - **clock ms** — wall-clock time spent in that package's own init functions. Because dependencies are separate entries earlier in the list, this number is that package's own work, not a cumulative subtree total. - **bytes / allocs** — heap bytes and allocation count attributed to that init. The format is documented as subject to change; read it, do not build a parser on it. ## What it deliberately does not print The runtime prints nothing for a package that has neither user-written nor compiler-generated init work, and nothing for inits performed as part of plugin loading. So the absence of a line for a package you expected does not mean its init was fast — it means there was no init work to do, or the package was not linked into this build at all because nothing reachable imports it. There is a second, subtler blind spot. The allocation counters are attributed only to the goroutine that runs init. If a package's `init` starts a goroutine that allocates heavily, none of that shows up in the `bytes` or `allocs` columns, and the `clock` column stops when `init` returns even though the goroutine it spawned is still running. A profile of long dead time where every line reports small numbers is a hint to look for exactly this — or for work that has been deferred into a background goroutine which `main` then waits on. ## What the typical culprit turns out to be In a batch job launched by a scheduler, the usual finding is a package that reads and parses a configuration file at package scope, or builds a large lookup table from it, or — worst — dials a remote service in `init`. All three make start-up cost proportional to something outside the program's control, and none of them can be logged, retried, timed out or reported on, because there is no `context.Context`, no logger and no error path in `init`: the only way to fail is to `panic`, which kills the process before anything is running to say why. The usual fix is not to make init faster, it is to stop doing the work there. Move it behind an explicit constructor the program calls from `main`, or behind a `sync.Once`-guarded lazy accessor. Then it is timeable, cancellable, loggable, and testable, and `inittrace` goes quiet because there is no init work left to report. ## Cost of turning it on `inittrace` is not entirely free: it puts the allocator on its accounting path so allocations on the init goroutine can be counted, and the runtime takes a timestamp around each package's init. The overhead is small and bounded to start-up, but it is a reason to treat this as a setting for a deliberate diagnostic run rather than a permanent fixture — which matches the rest of the GODEBUG family, whose output is unstructured stderr text aimed at a human. ## What good looks like in an answer A strong answer connects three facts: init runs before `main`, so nothing inside `main` can observe it; `inittrace` is set in the environment, so no rebuild is needed on a binary you cannot rebuild; and the lines are per package with the offsets telling you where the time went. A weaker answer reaches for a profiler or adds print statements to `main`, both of which arrive after the interesting part is over.