fix(core): treat pid 0 as dead in unix pid_is_alive - restores Check Ubuntu/macOS

[zackees]

Completes the main-restoration started in #1229 (follow-up to #1213 / #1227).

Summary

Check Ubuntu and Check macOS are still red on main after #1229: the two #1227 install-lock staleness tests fail there because the Unix pid_is_alive used kill(pid, 0) == 0, and kill(0, 0) probes the caller's own process group — so PID 0 always read as "alive" on Linux/macOS (Windows is unaffected, which is why it slipped through local dev and #1229's Windows leg passed).

Beyond the tests, this is a real production hole: a corrupt owner.txt recording pid=0 would read as a live owner on Unix and its install lock would never be reclaimed — the exact #1213 deadlock class the tests exist to prevent.

Fix: explicit pid-0 guard in the Unix pid_is_alive + a cross-platform regression test (pid_zero_is_never_alive).

This commit was originally pushed to the #1229 branch, but that PR had already been merged, so the push never attached — this PR carries the identical cherry-picked commit.

Validation

• Failure signature on main: install_lock::tests::lock_owned_by_a_dead_pid_is_stale_immediately and legacy_owner_record_without_exe_stem_still_uses_liveness fail on Check Ubuntu (job 91426903435) and Check macOS (job 91426904142); both pass on Windows.
• Local (Windows): soldr cargo test -p fbuild-core process_identity — 7 passed incl. the new test; soldr cargo test -p fbuild-packages-fetch install_lock — 12 passed.
• The Ubuntu/macOS legs of this PR's CI are the real proof — they exercise the guard.

🤖 Generated with Claude Code

[coderabbitai]

Warning

Review limit reached

@zackees, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 31 minutes

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro Plus

Run ID: a8a31f27-4471-44eb-9e33-625bdafbf38c

📥 Commits

Reviewing files that changed from the base of the PR and between fe9a672 and 8a4ca53.

📒 Files selected for processing (1)

• crates/fbuild-core/src/process_identity.rs

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}