Bug Description
When the OpenClaw gateway exits abnormally (e.g. TerminateProcess, power failure, OOM), the openclaw-runtime.lock/ directory and its owner.json remain on disk. On restart, if Windows assigns the same PID to the new process (common due to PID recycling), pidIsAlive() checks the stale owner PID which happens to be the current process's own PID and incorrectly reports that another OpenClaw instance is running.
Reproduction Steps
- Start openclaw gateway (gets PID e.g. 12345)
- Kill the process forcefully (not clean shutdown)
- Start openclaw gateway again
- If Windows assigns PID 12345 to the new process, the lock check fails
Root Cause
Missing self-PID check in pidIsAlive() at apps/memos-local-plugin/adapters/openclaw/runtime-lock.ts:104
The function process.kill(pid, 0) when pid === process.pid always succeeds (you can always signal yourself), so the function returns true even though the lock is from a previous instance.
Fix
Add one line in pidIsAlive() to exclude the current process PID:
if (pid === process.pid) return false;
Environment
- memos-local-plugin: 2.0.5
- OpenClaw: 2026.6.10
- OS: Windows 11
- Node: 22.x
Bug Description
When the OpenClaw gateway exits abnormally (e.g. TerminateProcess, power failure, OOM), the openclaw-runtime.lock/ directory and its owner.json remain on disk. On restart, if Windows assigns the same PID to the new process (common due to PID recycling), pidIsAlive() checks the stale owner PID which happens to be the current process's own PID and incorrectly reports that another OpenClaw instance is running.
Reproduction Steps
Root Cause
Missing self-PID check in pidIsAlive() at apps/memos-local-plugin/adapters/openclaw/runtime-lock.ts:104
The function process.kill(pid, 0) when pid === process.pid always succeeds (you can always signal yourself), so the function returns true even though the lock is from a previous instance.
Fix
Add one line in pidIsAlive() to exclude the current process PID:
if (pid === process.pid) return false;
Environment