Skip to content

Session lock files not cleaned up on hard reboot (pid reuse causes stale lock to appear live) #29927

@workingpleasewait

Description

@workingpleasewait

Summary

On hard reboot (or any ungraceful shutdown), session lock files written to ~/.clawdbot/agents/main/sessions/*.lock are not cleaned up. When the gateway restarts, it checks if the pid stored in the lock file is alive — but after a reboot, pids get reused by the OS. The reused pid (now belonging to a completely different process, e.g. clawmetry) is seen as "alive", so the gateway treats the stale lock as valid and refuses to open the session.

Reproduction

  1. Have an active session writing a lock file (e.g. pid 364)
  2. Hard reboot the machine
  3. On restart, pid 364 gets reused by a different process (e.g. clawmetry)
  4. Gateway starts, finds the lock file, checks if pid 364 is alive — it is, so it considers the lock held
  5. Any incoming message that triggers that session hits a 10s lock timeout and fails

Root Cause

The lock check verifies pid liveness but not process identity. A correct implementation should also verify that the pid belongs to a clawdbot process (e.g. check /proc/<pid>/cmdline or write a unique token into the lock file and verify it on read).

Workaround

Clear all *.lock files before the gateway starts on boot:

rm -f ~/.clawdbot/agents/main/sessions/*.lock

We added this to our pm2 startup wrapper as a temporary fix, but it should be handled by the gateway itself on startup.

Suggested Fix

When reading a lock file, verify process identity, not just liveness:

  • Check /proc/<pid>/cmdline contains clawdbot
  • Or write a unique session token into the lock file and verify it on read
  • Or clear stale locks on gateway startup before accepting connections

Environment

  • OS: Linux (OrbStack VM, arm64)
  • Node: v22.22.0
  • clawdbot: latest

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions