mac_unified_logging: fix infinite json.Decoder error loop (sustained ~113% CPU, silent collection stall)

[amrik-lc]

Fixes a bug in the mac_unified_logging adapter observed in the field as sustained ~113% CPU on macOS — with the worse side effect that the adapter had silently stopped collecting logs entirely. Tracked in refractionPOINT/tracking#4458.

Root cause

StartGathering dropped the first line of log stream --style=ndjson output using a throwaway bufio.Reader, which buffers (and then discards) up to 64KB beyond that first line. Depending on startup timing, the json.Decoder created afterwards starts reading mid-JSON-object and returns a SyntaxError. Go's json.Decoder never advances its input past a syntax error, so the read loop degenerated into a permanent hot loop:

• failed Decode + two fmt.Println per iteration, forever → ~1 core pegged (plus GC churn)
• the stdout pipe is never read again → it fills → log stream blocks forever in write() → zero events ingested until the process is restarted

Diagnosed from a process sample (all on-CPU time under StartGathering.func1 → fmt.Fprintln/encoding/json.(*SyntaxError).Error) and a spindump showing the log child's output thread blocked in write() since the moment it was forked, days earlier.

Fix

• Parse the ndjson output line by line with a bufio.Scanner (4MB max line) and json.Unmarshal each line, skipping lines that fail to parse. The non-JSON "Filtering the log data..." header is skipped naturally, so the racy drop-first-line hack is gone. A bad line can now never wedge the stream.
• Close logs.Channel when the stream ends, so the adapter terminates (and can be restarted by its supervisor) instead of hanging silently if log stream dies.
• Make StopGathering close-based (sync.Once + close(exit)): idempotent and non-blocking, where the old unbuffered send could block forever if the gatherer wasn't at the select. A watcher goroutine kills the subprocess on stop so a reader blocked in Scan() unblocks.
• Check cmd.Start()'s error and return it from StartGathering (was previously ignored inside the goroutine).
• stderr watcher: panic with the actual stderr line instead of panic(err) on a stale nil error from the enclosing scope (which produced a meaningless panic(nil)).
• client.go: buffer the signal.Notify channel (pre-existing go vet finding; unbuffered signal channels can drop the signal).

Verification

• gofmt -l clean; go build and go vet pass for GOOS=darwin GOARCH=arm64 and GOOS=linux on the package.
• Behavior change on decode errors: instead of looping on the same error, the adapter skips the offending line and continues with the next one; if the stream itself ends, the adapter exits instead of spinning.

🤖 Generated with Claude Code