Detect stale dev server lock files after PID reuse - #17671
Conversation
The lock file liveness check relied on process.kill(pid, 0), which only proves that some process owns the PID. After a Docker container restart the PID is quickly reused by an unrelated process while the lock file persists on the volume mount, so astro refused to start. The lock file now records the kernel start time from /proc/<pid>/stat alongside the PID, and the check verifies both. Lock files written by older versions are only treated as stale when the recorded process clearly started after the lock file was written (5s margin for soft clocks). Platforms without /proc keep the previous PID-existence check. Closes withastro#17656
🦋 Changeset detectedLatest commit: 4c3d302 The changes in this PR will be included in the next version bump. This PR includes changesets to release 417 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
|
Thanks for taking this on. Given that this is Linux-only we can't go with this type of solution. What about using something like https://www.npmjs.com/package/process-ancestry and then check the command and see if its Astro? |
|
Thanks for the pointer! I checked I switched this to Pushed in 4c3d302. Hope this helps! |
Closes #17656
Changes
--forcefrom signalling an unrelated process when the command can be verified.Testing
.cmdshim and unrelated commands.Docs
No docs update needed because the CLI workflow and user-facing messages stay the same.