Description
Follow-up from PR #6692 (#6683/#6682). The chrome_guard's FlushGuard had a gap where a foreground CLI/TUI process killed via pkill's default SIGTERM would skip Drop, leaving the local trace JSON file truncated — fixed in #6692 via a shared take-once cell plus a SIGTERM listener.
log_guard (the rolling file appender's WorkerGuard, in the same src/tracing_init.rs init path) has the same theoretical gap: it also relies on Drop running to flush buffered log writes, and a SIGTERM-without-handler from pkill would skip that Drop the same way chrome_guard's did before the fix.
This was explicitly out of scope for #6692 (issue was scoped to chrome_guard/build_chrome_layer only) and left untouched.
Evidence so far
Live-tested during #6692's review: a pkill -TERM repro did not truncate the log file in that specific run — the tester's working theory is that tracing-appender's rolling file writer streams continuously rather than buffering until Drop, so it may not need the same fix. But this was not verified as a structural guarantee (no explicit flush-before-exit exists for log_guard, unlike the new chrome_guard mechanism) — it survived by observation, not by design.
Expected Behavior
Determine whether log_guard genuinely needs the same take-once-cell + SIGTERM-listener treatment as chrome_guard, or whether tracing-appender's write behavior makes it structurally safe already. If the former, apply the same pattern (the shared cell infrastructure from #6692 could likely be generalized to cover both guards).
Reproduction Steps
- Run a live session with logging enabled (
RUST_LOG=debug, file output configured).
- Kill the process with
pkill -f "target/.*zeph" mid-session, ideally with a burst of log writes in flight.
- Inspect the resulting log file for truncation/missing tail content.
Environment
- Version: unreleased (main, as of 2026-07-28)
- Relevant code:
src/tracing_init.rs (log_guard field, alongside the now-fixed chrome_guard)
Description
Follow-up from PR #6692 (#6683/#6682). The
chrome_guard'sFlushGuardhad a gap where a foreground CLI/TUI process killed viapkill's defaultSIGTERMwould skipDrop, leaving the local trace JSON file truncated — fixed in #6692 via a shared take-once cell plus a SIGTERM listener.log_guard(the rolling file appender'sWorkerGuard, in the samesrc/tracing_init.rsinit path) has the same theoretical gap: it also relies onDroprunning to flush buffered log writes, and aSIGTERM-without-handler frompkillwould skip thatDropthe same waychrome_guard's did before the fix.This was explicitly out of scope for #6692 (issue was scoped to
chrome_guard/build_chrome_layeronly) and left untouched.Evidence so far
Live-tested during #6692's review: a
pkill -TERMrepro did not truncate the log file in that specific run — the tester's working theory is thattracing-appender's rolling file writer streams continuously rather than buffering untilDrop, so it may not need the same fix. But this was not verified as a structural guarantee (no explicit flush-before-exit exists forlog_guard, unlike the newchrome_guardmechanism) — it survived by observation, not by design.Expected Behavior
Determine whether
log_guardgenuinely needs the same take-once-cell + SIGTERM-listener treatment aschrome_guard, or whethertracing-appender's write behavior makes it structurally safe already. If the former, apply the same pattern (the shared cell infrastructure from #6692 could likely be generalized to cover both guards).Reproduction Steps
RUST_LOG=debug, file output configured).pkill -f "target/.*zeph"mid-session, ideally with a burst of log writes in flight.Environment
src/tracing_init.rs(log_guardfield, alongside the now-fixedchrome_guard)