Issue Station
Sign In
Tools hereToolbox

openclaw - ✅(Solved) Fix [Bug]: Session lock file not released on graceful shutdown, causes 50%+ CPU in busy-wait loop [1 pull requests, 1 comments, 2 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openclaw/openclaw#75805•Fetched 2026-05-02 05:29:46
View on GitHub
Comments
1
Participants
2
Timeline
5
Reactions
3
Author
keldmexkeldmex
Participants
clawsweeper[bot]clawsweeper[bot]keldmexkeldmex
Timeline (top)
cross-referenced ×2closed ×1commented ×1labeled ×1

OpenClaw gateway leaves session lock files in a stuck state after restart, causing a busy-wait loop that consumes 50%+ CPU until the lock file is manually deleted.

Root Cause

Root Cause (hypothesis)

Fix Action

Fix / Workaround

Workaround rm /root/.openclaw/agents/main/sessions/<session-id>.jsonl.lock Immediate effect: CPU drops 50%, responsiveness restored.

PR fix notes

PR #75822: fix(agents): reclaim untracked self-owned session locks

Description (problem / solution / changelog)

Summary

  • Reclaim current-process session locks with matching starttime when they are no longer tracked in HELD_LOCKS.
  • Share orphan-self classification between lock acquisition and stale .jsonl.lock cleanup.
  • Preserve active in-process locks and fresh legacy current-PID locks.

Fixes #75805 Related #49603

Test Plan

  • corepack pnpm exec vitest run --config test/vitest/vitest.agents-core.config.ts src/agents/session-write-lock.test.ts
  • corepack pnpm exec vitest run --config test/vitest/vitest.commands.config.ts src/commands/doctor-session-locks.test.ts
  • corepack pnpm exec node scripts/run-tsgo.mjs -p tsconfig.core.test.agents.json --incremental --tsBuildInfoFile .artifacts/tsgo-cache/core-test-agents.tsbuildinfo
  • corepack pnpm exec oxfmt --check --threads=1 src/agents/session-write-lock.ts src/agents/session-write-lock.test.ts

Changed files

  • CHANGELOG.md (modified, +1/-0)
  • src/agents/session-write-lock.test.ts (modified, +49/-0)
  • src/agents/session-write-lock.ts (modified, +64/-23)
RAW_BUFFERClick to expand / collapse

Bug type

Regression (worked before, now fails)

Beta release blocker

No

Summary

OpenClaw gateway leaves session lock files in a stuck state after restart, causing a busy-wait loop that consumes 50%+ CPU until the lock file is manually deleted.

Steps to reproduce

  1. Run OpenClaw gateway for extended period
  2. Run a task (even internal self-test) that times out or hangs
  3. Restart the gateway: systemctl restart openclaw.service
  4. Observe: CPU remains 48-52% despite no active workload
  5. Fix: Manually delete lock file: rm /root/.openclaw/agents/main/sessions/<session-id>.jsonl.lock
  6. Observe: CPU drops to 15-20% immediately

Environment

• OpenClaw: 2026.4.29 • OS: Ubuntu 22.04 LTS on Hetzner • Node: v22.22.2

Details

Syscall pattern showing the busy-wait loop (30-second sample): 47.6% epoll_pwait — waiting for I/O that never resolves 16.3% openat — repeatedly opening session file 14.2% read — trying to read 13.2% close — releasing handles 5.8% futex — lock contention Total: ~1,000 syscalls/sec, spinning on the same session lock.

Lock file content: { "pid": 2452, "createdAt": "2026-05-01T20:18:48.682Z", "starttime": 252434 } Lock was created at gateway restart but never released. Gateway was trying to acquire/release the same lock in a tight loop.

Session file path: /root/.openclaw/agents/main/sessions/<session-id>.jsonl.lock

Root Cause (hypothesis)

The session lock mechanism expects clean lock file cleanup on exit, but:

  1. A task hung for 110+ minutes before being reaped
  2. Gateway restart didn't orphan/cleanup the lock properly
  3. Gateway tried to re-acquire the lock on startup but hit a condition that prevented release
  4. Result: infinite loop in the lock acquisition/release logic

Impact

• Gateway becomes unresponsive (1+ second response delays) • High CPU usage makes the system sluggish • Requires manual intervention (SSH in + delete lock file) to recover • User experience: feels like a crash/hang

Workaround rm /root/.openclaw/agents/main/sessions/<session-id>.jsonl.lock Immediate effect: CPU drops 50%, responsiveness restored.

Expected Behavior

• Gateway should clean up stale lock files on startup • Lock acquisition should have a timeout to prevent infinite waits • Hung tasks should be auto-reaped with a configurable timeout • Or: add a --force-lock-cleanup flag to openclaw gateway restart

───

Or use the CLI to file it:

If you have gh (GitHub CLI) installed: gh repo clone openclaw/openclaw cd openclaw gh issue create
--title "Session lock file not released on graceful shutdown, causes 50%+ CPU in busy-wait loop"
--body "$(cat << 'EOF' [paste the description above] EOF )"

Expected behavior

Normal system performance

Actual behavior

Normal system performance

OpenClaw version

2026.4.29

Operating system

Ubuntu 22.04 LTS on Hetzner

Install method

No response

Model

Anthroibic

Provider / routing chain

Openclaw - anthrobic

Additional provider/model setup details

No response

Logs, screenshots, and evidence

Impact and severity

No response

Additional information

No response

extent analysis

TL;DR

The OpenClaw gateway leaves session lock files in a stuck state after restart, causing a busy-wait loop, and can be temporarily fixed by manually deleting the lock file.

Guidance

  • The issue is likely caused by the gateway not properly cleaning up lock files on exit, leading to an infinite loop when trying to re-acquire the lock on startup.
  • To verify, check the CPU usage and syscall pattern after restarting the gateway to see if it enters a busy-wait loop.
  • A potential workaround is to add a script to automatically delete lock files on gateway restart, or to implement a timeout for lock acquisition to prevent infinite waits.
  • The --force-lock-cleanup flag could be added to the openclaw gateway restart command to force cleanup of stale lock files.

Example

No code example is provided as the issue does not imply a specific code change, but rather a configuration or flag change.

Notes

The provided information suggests that the issue is related to the gateway's lock mechanism and its handling of stale lock files. However, without more information about the gateway's internal workings, it's difficult to provide a definitive solution.

Recommendation

Apply workaround: Manually delete lock files or implement a script to do so on gateway restart, as this provides an immediate fix to the high CPU usage and busy-wait loop issue.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

FAQ

Expected behavior

Normal system performance

#api#ssr#memory leak#API versioning#request timeout

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

openclaw - ✅(Solved) Fix [Bug]: Session lock file not released on graceful shutdown, causes 50%+ CPU in busy-wait loop [1 pull requests, 1 comments, 2 participants]