Fix service process state data race

[yaroslavvoloshchuk-codaio]

Summary

• snapshot exec.Cmd.ProcessState under ServiceInstance's existing mutex after Cmd.Wait completes
• route service process-state reads through the synchronized snapshot
• add a Linux race-detector regression test in the existing tests workspace

Why

Cmd.Wait writes Cmd.ProcessState while Runner.StopAll and health checks may read it concurrently. The Go race detector reports that unsynchronized access in #71.

The snapshot preserves the existing ProcessState() API and is reset when a service command is reinitialized.

Regression test

The test uses target-local -no-pie because rules_go race mode requires external linking and the registered hermetic LLVM toolchain hits golang/go#76825: the linker probe drops required hermetic flags, misses -no-pie, and then rejects Go's position-dependent objects under PIE semantics. This flag affects only the Linux race-regression target.

Validation

• before the fix, the focused test reproduced the Cmd.Wait / ProcessState() race under go test -race
• GOWORK=/tmp/rules-itest-issue71-go.work go test -race -vet=off ./process_state_race -run '^TestProcessStateAccessIsSynchronized$' -count=1
• bazel build //runner/...
• exact-head full workflow run at 557bbc529ee1ab166322bd7990a5c4f73cad2cd4
  • Ubuntu: 43/43 tests passed; the new race target passed in 3.0s
  • Windows: 37 tests passed and six platform-incompatible tests, including the Linux-only race target, were skipped

Fixes #71.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 557bbc529e

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Do not leave ProcessState nil while WaitDelay is pending

For services whose child has already been reaped by the background Wait but Cmd.Wait is still waiting for copied stdout/stderr to finish or for the 50ms WaitDelay (for example, an exited service with a descendant holding stdout open), killGroup in StopWithSignal can return ESRCH and StopAll immediately records serviceInstance.ProcessState(). Since the snapshot is not assigned until after cmd.Wait() returns here, StopAll can return a nil state, and cmd/svcinit/main.go dereferences it when printing state.UserTime()/SystemTime(). Previously the direct cmd.ProcessState read was populated as soon as Process.Wait reaped the child, before WaitDelay, so this shutdown path still had a state.

Useful? React with 👍 / 👎.