OpenClaw #114234 — Usage-Cost Refresh Lock Never Releasable Under Container PID Reuse

1 · Symptom Summary

2 · Root Cause Analysis

F-1: PID liveness is not lock ownership

The lock file records {pid, startedAt, token}, but staleness is judged with isProcessRunning(lock.pid) alone. That test answers "is some process alive at this PID?" — not "is the process that wrote this lock alive?". In any environment where PIDs are stable across restarts (containers under tini, minimal PID namespaces, supervisors that respawn into low PIDs), the two questions have different answers, and the code conflates them:

lock payload owner : pid=9  startedAt=2026-07-15 10:35:21 CST
ACTUAL pid 9 start : 2026-07-24 12:58:39 CST   # container restarted; PID reused
delta              : 9.10 days                 # lock still honoured

The bitter irony: parseRefreshLock() already parses and validates startedAt, and the writer already records it. The one comparison that would detect reuse — recorded startedAt vs. actual process start time — is simply never made. This is a classic identity-vs-address bug: a PID is an address, not an identity.

F-2 / F-3: Silent degradation, loud failure elsewhere

The frozen cache never throws. It degrades every consumer into a full transcript recompute whose cost grows daily, until an unrelated fixed timeout (the 60s cron setup watchdog) starts firing. The error message points at cron, not at the lock — which is why the reporter's failure-rate table is such a valuable forensic artifact: the very first failure is the next scheduled run after the lock appeared.

3 · Fix Plan (with code)

F-1 → Compare identity, not just liveness

// staleness check: the lock's startedAt must be >= the current
// occupant's process start time, else the writer is a dead incarnation
function isLockLive(lock) {
  if (!isProcessRunning(lock.pid)) return false;
  const procStart = getProcessStartTime(lock.pid);   // /proc/<pid>/stat field 22
  if (procStart > lock.startedAt) return false;      // PID reused by a newer process
  return true;
}

Alternative shapes, strongest first:

• OS-level flock — lock dies with the process, even on SIGKILL. Zero staleness logic needed; costs some portability care.
• Per-incarnation nonce — write a boot-time UUID into the lock and into a live heartbeat file; ownership requires both to match.
• Hard expiry bound — if startedAt exceeds N× the worst observed refresh duration, force-release regardless. Belt and braces.

Candidate upstream fix

PR #114254 (by the issue reporter) targets exactly this ownership-comparison route and is the canonical candidate per ClawSweeper's review. The fix shape matches what the on-disk lock format already records — no new state needed.

4 · Stopgap Checklist (until patched)

• ☐ Delete the orphaned lock file: rm .../.usage-cost-cache.json.lock — reporter confirmed refresh resumes within seconds
• ☐ Add a liveness probe: alert if the usage-cost cache mtime is older than ~1 hour
• ☐ In entrypoint scripts, consider clearing stale locks whose startedAt predates container boot time
• ☐ Watch isolated-cron failure rates: a slow climb pinned at exactly the watchdog duration (60s) is a signature of upstream state starvation, not of cron itself
• ☐ If on NFS, remember it amplifies recompute cost but is not required to hit the bug

5 · Prevention — the ARK pattern

This failure chain belongs to classes ARK guards against in agent systems:

pip install ark-trust        # Python
npm install @feilunxitong/arkit   # TypeScript