A PID is not a permanent identity
Linux assigns a numeric process identifier to each running process. Software often stores that PID so it can later ask whether a background worker is still alive. The check looks reasonable until the machine reboots or enough processes are created for the number to be reused.
Imagine OpenPuzzle stores PID 65833 for an engine, the machine loses power and later boots again. A different application may eventually receive PID 65833. Code that checks only “does PID 65833 exist?” could incorrectly decide that the old OpenPuzzle engine survived. A stop path could be even worse if it signalled that unrelated process.
Binding state to the Linux boot identity
Linux exposes a boot identifier in /proc/sys/kernel/random/boot_id. OpenPuzzle 1.0.17 stores this identifier alongside persisted process state. A saved process is considered potentially active only when the stored boot ID matches the current boot ID and the PID still exists.
If the boot IDs differ, the state is stale regardless of whether Linux has already reused the numeric PID. Legacy state from releases that did not record a boot ID is not trusted from PID alone. If the current boot identity cannot be read, recovery fails closed instead of guessing.
Applying the rule consistently
The fix is not limited to one status command. Runtime markers, background supervisor state, process monitoring, heartbeat checks, stop handling and update logic all need the same identity rule. A partial fix would still leave a path where a reused PID could be mistaken for an OpenPuzzle process.
Safe launch behavior
New execution state also needs a valid boot identity before it becomes durable. OpenPuzzle reads the current boot identity before persisting unsafe process state. If that cannot be obtained, the just-launched worker is stopped and the run fails rather than leaving ambiguous state behind.