---
name: pid-reuse-across-reboot
description: "Pid-only liveness probes are unsound — a reused pid reads ALIVE and can wedge the very command that recovers the instance. Reboot is the obvious window; MEASURED on this box, reuse also lands inside 30 SECONDS of the same boot. Birth-stamp the pid."
metadata: 
  node_type: memory
  type: project
  originSessionId: 709471f7-927d-4b0b-934d-0b9c919a2d08
  modified: 2026-08-03T15:59:21.988Z
---

`spt_store::shellinfo::shell_pid_provably_dead` probes by pid alone and its
docstring accepts the miss ("recycled pids read alive, so a heal can be missed but
never mis-fired"). Its stated escape — that reuse is rare enough during
steady-state operation — **is false on this box, measured**. Reboot only makes it
worse: the pid namespace resets, so a stale `shell.pid` is likely to be reused.
It is also worse than "missed" — a
reused pid makes `effective_status` read `online`, which makes
`relink_shell_from` (`linkhost.rs:499-501`) refuse `SHELL_ALREADY_ONLINE`, i.e.
the one command that recovers the instance refuses on the exact state that is
wrong. Only exit left is teardown + spawn (canonical-id churn).

Live near-miss, HFENDULEAM 2026-08-01: `owlery/perri/shells/PACER-0/shell.pid`
recorded 7736, and 7736 was `svchost.exe` by then. It still derived `offline` ONLY
because `is_process_alive` uses `OpenProcess(PROCESS_QUERY_LIMITED_INFORMATION)`
and a non-elevated token cannot open a SYSTEM-owned process — ACCESS_DENIED reads
as dead. Reuse onto a *user-owned* process would read alive and wedge it.
**Same-boot recycle, MEASURED, HFENDULEAM 2026-08-03:** during a CWD sweep of the
process table, pid **41356** was an `spt_daemon` test harness in one sample and a
22-second-old `PING` process thirty seconds later. Same boot, no restart anywhere
in the scenario, ~30s between reuse — and both occupants were user-owned, so the
ACCESS_DENIED accident that saved the 2026-08-01 near-miss would not have applied.
That is the incidence number the code read could not supply, and it is small enough
that "rare during steady-state" is not a defensible premise for any probe on this
box. Every reap or liveness check that selects by BARE PID is living on a
thirty-second margin. Same hazard as spt-bs-releases#134, observed in the wild
rather than argued from a record.

Filed in the addendum of
spt-bs-releases#78 (BACKLOG/BUGFIX, next-batch beside #74/#76); perri's PACER-0 is
left standing as the live specimen and perri is told to stop-and-report if relink
ever refuses on a known-down shell.

**Why:** the sound primitive already exists one layer up — agent perches carry
`pid_started_at` (`info.rs:272`) and probe through
`liveness::relay_liveness(pid, pid_started_at)`. Shell records carry no such
field. Same one-step-short pattern `effective_status`'s own docstring names
("REQ-HAZARD-DAEMON-HOSTED-LIVENESS gave agent perches exactly this; shells never
got it") repeating at the next layer: shells got the derived status, not the
birth-stamped identity the derivation needs to be sound.

**How to apply:** never accept a bare-pid liveness probe as proof a process is
gone — demand pid + start-time. Do NOT scope the objection to "if a restart is in
the scenario"; that scoping is what the 30-second same-boot recycle refutes.
Related: [[stale-breadcrumb-tree-kill-class]] (pid reuse on the kill side),
[[derived-view-vs-on-disk-record]] (the process table is the only trustworthy
Windows liveness source), [[setup-suppresses-failing-arm]].