PR #74361: fix(plugins): disambiguate runtime-deps lock owners by process start-time (Docker PID reuse)

• Repository: openclaw/openclaw
• Author: jhsmith409
• State: closed | merged: True
• Link: https://github.com/openclaw/openclaw/pull/74361

Description (problem / solution / changelog)

Summary

shouldRemoveRuntimeDepsLock short-circuits on isAlive(owner.pid) alone, which is unsafe inside containers because PIDs are recycled deterministically — the new gateway is always PID 1 (or PID 7 with init: true) in its container PID namespace, so a stale lock left behind by a previous incarnation looks "live" to the new one and never gets reclaimed.

This PR captures pidStartTimeMs at lock-acquisition time and consults it in the staleness check. When both sides have start-time evidence and they disagree, the lock is treated as stale. When evidence is missing on either side (legacy locks, non-Linux hosts), the existing PID-alive-means-fresh behavior is preserved exactly.

Closes #74346.

The bug

Setup: OpenClaw on Docker (ghcr.io/openclaw/openclaw:2026.4.24+), Linux host. Reproduced both with docker compose down/up and with a hard-killed gateway (sigkill, OOM, container kill).

1. Old gateway dies without graceful cleanup — .openclaw-runtime-deps.lock/owner.json is left behind with {"pid": 7, "createdAtMs": <T0>}.
2. New container starts. The new Node process becomes PID 7 in its namespace.
3. Lock-acquisition path calls removeRuntimeDepsLockIfStale(lockDir, nowMs), which calls shouldRemoveRuntimeDepsLock(owner, nowMs). Owner has pid: 7. isAlive(7) returns true (the new process is PID 7). The function returns false — lock stays.
4. mkdirSync(lockDir) returns EEXIST. The wait loop spins until BUNDLED_RUNTIME_DEPS_LOCK_TIMEOUT_MS (5 min) elapses, then errors out and is restarted by the supervisor. Cycle repeats indefinitely.

Operators have been working around this by stopping the container and manually removing .openclaw-runtime-deps.lock. After lock removal the gateway boots in ~35 seconds.

The fix

Strictly-additive change to the lock owner record and the staleness predicate:

1. New pidStartTimeMs field on the lock owner record. Computed once at module load as Date.now() - process.uptime() * 1000 and persisted alongside pid / createdAtMs in owner.json.
2. New readProcessStartTimeMs(pid) helper that returns the live PID's start-time in epoch ms on Linux (parses /proc/<pid>/stat field 22, anchored on the last ) to handle process names with spaces/parens), or null elsewhere. Hard-coded 100 for _SC_CLK_TCK since the constant cancels out — both ends of the comparison use the same conversion.
3. shouldRemoveRuntimeDepsLock extended: when owner.pidStartTimeMs is set AND readStartTimeMs(owner.pid) returns a value AND the two disagree, the lock is stale. When evidence is missing on either side, the existing PID-alive-means-fresh path is taken unchanged.

Why strictly additive

• Wire format: lock files written by older releases lack pidStartTimeMs. They continue to take the legacy path. No migration step needed.
• Predicate: when start-time evidence cannot be confirmed (legacy lock, non-Linux host), behavior is identical to today's code. The pre-existing test does not expire active runtime-deps install locks by age alone continues to pass.
• Platforms: macOS / Windows hosts return null from readProcessStartTimeMs (no /proc) and take the legacy path. Linux hosts (including Docker Desktop's Linux VM, which all Linux containers run inside on macOS / Windows) get the disambiguation.

Tests

src/plugins/bundled-runtime-deps.test.ts adds four new cases:

• matching start-time → lock is fresh (same incarnation re-checking its own lock).
• mismatched start-time, PID alive → lock is stale (the Docker PID-reuse case this PR targets).
• PID alive, no live start-time available → fall back to legacy behavior. Asserts that even with pidStartTimeMs set on the owner, we don't stomp the lock when the live side cannot be verified.
• (existing test) does not expire active runtime-deps install locks by age alone → still passes unchanged, because the legacy path is preserved exactly when evidence is missing.

All 94 tests in bundled-runtime-deps.test.ts pass locally.

Verified

• pnpm vitest run --reporter verbose --no-coverage src/plugins/bundled-runtime-deps.test.ts — 94/94 pass.
• pnpm tsc --noEmit -p tsconfig.json — no new errors related to this file.

Notes for review

• The capture timing (Date.now() - process.uptime() * 1000) drifts a few ms relative to /proc's starttime jiffies. That's fine because the comparison only runs against the same PID's start-time read from /proc later — equality holds within rounding tolerance and we use Math.round on both sides.
• I deliberately kept this as a "fix the predicate" change rather than a flock(2) rewrite. A flock-based design (kernel-released on process exit, no staleness logic needed) would be cleaner architecturally but is a much larger change and would require picking a Node lockfile library. Happy to follow up with an RFC if you'd like to go that direction; this PR addresses the immediate Docker hang while preserving every existing invariant.

Changed files

• CHANGELOG.md (modified, +1/-0)
• src/plugins/bundled-runtime-deps.test.ts (modified, +45/-0)
• src/plugins/bundled-runtime-deps.ts (modified, +49/-4)
• ui/src/ui/components/dashboard-header.ts (modified, +2/-2)