Go deployment ends at log.Fatal without cleanup or stack trace

Direct Answer

Yes. Centralize cleanup and exit-status mapping outside log.Fatal. The standard library's log.Fatal calls os.Exit(1) immediately, so deferred functions never run, buffered writers are not flushed, and no stack trace is emitted. A single shutdown function invoked from main, a top-level recover, signal handling, and HTTP server logic preserves diagnostics and runs cleanup for every termination path.

Where Responsibility Lives

Place the contract in main or a dedicated lifecycle package owned by the service entry point. It should own:

• Structured stderr logging with stack capture via runtime/debug.Stack
• An idempotent cleanup registry for database closes, tracer flushes, and temp-file removal
• An exit-code mapping table
• Unbuffered stderr, or an explicit Flush before os.Exit

Third-party libraries that call log.Fatal internally bypass this contract; audit dependencies or wrap their entry points.

Exit-Code Mapping and Stderr Fields

Use JSON Lines on stderr so collectors can parse fields without regex. Recommended mapping for maintained Go 1.x on Linux:

Termination path	Exit code	level	Stack trace
Graceful HTTP shutdown (http.ErrServerClosed)	0	shutdown	No
Explicit fatal error	1	fatal	Yes
Recovered panic after cleanup	3	panic	Yes
SIGINT	130	signal	Yes
SIGTERM	143	signal	Yes
Other signals	128+signo	signal	Yes

Example stderr line:

{"level":"fatal","msg":"database connection failed","exitCode":1,"stack":"..."}

Assumptions: http.Server.Shutdown returns nil on success and Server.Serve then returns http.ErrServerClosed; treat that as graceful shutdown, not an error. Windows lacks SIGTERM/SIGINT parity, and container runtimes may remap exit codes, so verify the final code seen by your orchestrator.

Local Verification

1. Start the binary and capture exit code and stderr for each path: explicit fatal, recovered panic, SIGINT, SIGTERM, and graceful Server.Shutdown.
2. Assert exactly one JSON line per run with matching level and exitCode.
3. Confirm an idempotent cleanup side-effect, such as removal of a marker file, runs in every path including explicit fatal.
4. Verify a stack trace appears for fatal, panic, and signal, but not for shutdown.
5. Repeat under docker run --init to confirm signal propagation matches production.

Missing Diagnostic Detail

What log output destination and buffering mode does your deployment use—for example, journald, a file assigned with log.SetOutput, or container stdout/stderr? This determines whether an explicit Flush or an unbuffered writer is required before os.Exit.