#Startup issue

1 messages · Page 1 of 1 (latest)

winter kiln
#

Suddenly openclaw is not starting up well for me. it is taking a long time to do anything, the only thing I see is this

[channels] failed to load bundled channel discord: Timed out waiting for bundled runtime deps lock at /home/node/.openclaw/plugin-runtime-deps/openclaw-2026.4.26-f53b52ad6d21/.opownerFilePath=/home/node/.openclaw/plugin-runtime-deps/openclaw-2026.4.26-f53b52ad6d21/.openclaw-runtime-mirror.lock/owner.json). If no OpenClaw/npm install is running, remove thock'

light moonBOT
#

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> âś… Mark Solution

granite cedarBOT
#

That’s a bundled plugin runtime-deps lock getting stuck, likely from an interrupted startup/update. First: what does openclaw --version show?

If nothing is currently installing/updating, stop OpenClaw, remove only the lock dir, then restart:

openclaw gateway stop

rm -rf /home/node/.openclaw/plugin-runtime-deps/openclaw-2026.4.26-f53b52ad6d21/.openclaw-runtime-mirror.lock

openclaw gateway start

Then run:

openclaw status --all
#
openclaw doctor

Also: that /home/node/.openclaw/plugin-runtime-deps path looks Docker-ish. Current Docker setup should keep generated plugin runtime deps in a Docker volume at /var/lib/openclaw/plugin-runtime-deps, not inside the config bind mount. If you’re using Docker/Compose, I’d update to the latest OpenClaw image/compose config and make sure OPENCLAW_PLUGIN_STAGE_DIR=/var/lib/openclaw/plugin-runtime-deps is set.

Docs:
https://docs.openclaw.ai/help/faq
https://docs.openclaw.ai/install/docker
https://docs.openclaw.ai/gateway/doctor

winter kiln
#

Can I delete the old directories? When is this runtime-deps generated?

$ du -sh /home/node/.openclaw/plugin-runtime-deps/*
1.1G /home/node/.openclaw/plugin-runtime-deps/openclaw-2026.4.24-f53b52ad6d21
1.4G /home/node/.openclaw/plugin-runtime-deps/openclaw-2026.4.25-f53b52ad6d21
1.4G /home/node/.openclaw/plugin-runtime-deps/openclaw-2026.4.26-f53b52ad6d21
779M /home/node/.openclaw/plugin-runtime-deps/openclaw-unknown-1a3ee78ac449

granite cedarBOT
#

Yes — those plugin-runtime-deps dirs are generated cache/state, not your config/auth/session data.

They’re generated when OpenClaw starts or when openclaw doctor --fix/channel setup needs to repair bundled plugin dependencies. Each OpenClaw package/version can get its own staged runtime tree, which is why you have 2026.4.24, .25, .26, plus an older openclaw-unknown-*.

Safest cleanup:

openclaw gateway stop

If you’re on 2026.4.26, you can delete the old ones:

rm -rf /home/node/.openclaw/plugin-runtime-deps/openclaw-2026.4.24-f53b52ad6d21
rm -rf /home/node/.openclaw/plugin-runtime-deps/openclaw-2026.4.25-f53b52ad6d21
rm -rf /home/node/.openclaw/plugin-runtime-deps/openclaw-unknown-1a3ee78ac449
#

For the current broken lock, either remove just the lock:

rm -rf /home/node/.openclaw/plugin-runtime-deps/openclaw-2026.4.26-f53b52ad6d21/.openclaw-runtime-mirror.lock

Or delete the whole current 2026.4.26 dir too; OpenClaw will regenerate it, but startup will be slower once:

rm -rf /home/node/.openclaw/plugin-runtime-deps/openclaw-2026.4.26-f53b52ad6d21

Then:

openclaw gateway start
#

If this is Docker, newer Compose expects this cache under /var/lib/openclaw/plugin-runtime-deps via OPENCLAW_PLUGIN_STAGE_DIR, instead of inside /home/node/.openclaw. Worth updating the compose file/image after you’re unstuck.

Docs: https://docs.openclaw.ai/install/docker

winter kiln
#

Can you make a bash script that deletes all the dirs in this runtime-deps that doesn't match the version of 'openclaw --version'

granite cedarBOT
#

Yep — I’d make it dry-run by default and only delete with --apply.

#!/usr/bin/env bash
set -euo pipefail

RUNTIME_DEPS_DIR="${1:-${OPENCLAW_PLUGIN_STAGE_DIR:-$HOME/.openclaw/plugin-runtime-deps}}"
APPLY="${APPLY:-0}"

VERSION="$(openclaw --version | awk '{print $NF}')"

if [[ -z "$VERSION" ]]; then
  echo "Could not determine OpenClaw version from: openclaw --version"
  exit 1
fi
#
if [[ ! -d "$RUNTIME_DEPS_DIR" ]]; then
  echo "Runtime deps dir does not exist: $RUNTIME_DEPS_DIR"
  exit 1
fi

echo "OpenClaw version: $VERSION"
echo "Runtime deps dir: $RUNTIME_DEPS_DIR"
echo

for dir in "$RUNTIME_DEPS_DIR"/*; do
  [[ -d "$dir" ]] || continue

  base="$(basename "$dir")"

  if [[ "$base" == openclaw-"$VERSION"-* ]]; then
#
    echo "KEEP   $dir"
  else
    if [[ "$APPLY" == "1" ]]; then
      echo "DELETE $dir"
      rm -rf -- "$dir"
    else
      echo "WOULD DELETE $dir"
    fi
  fi
done

echo
if [[ "$APPLY" != "1" ]]; then
  echo "Dry run only. To actually delete, run:"
  echo "  APPLY=1 $0 \"$RUNTIME_DEPS_DIR\""
#
fi

Use it like:

nano cleanup-runtime-deps.sh
chmod +x cleanup-runtime-deps.sh
./cleanup-runtime-deps.sh /home/node/.openclaw/plugin-runtime-deps

If it looks right:

openclaw gateway stop
#
APPLY=1 ./cleanup-runtime-deps.sh /home/node/.openclaw/plugin-runtime-deps
openclaw gateway start

It keeps dirs matching openclaw-$(openclaw --version)-* and deletes old version dirs plus openclaw-unknown-*.

winter kiln
#

What is the .openclaw-runtime-mirror.lock directory?

granite cedarBOT
#

.openclaw-runtime-mirror.lock is just a filesystem lock directory OpenClaw creates while it prepares the bundled plugin “runtime mirror”.

Plain English: when OpenClaw starts, bundled plugins like Discord may need files/deps staged into plugin-runtime-deps/. The lock prevents two processes — gateway startup, doctor --fix, update, another container, etc. — from writing that same generated cache at the same time.

Inside it there’s usually an owner.json with the PID/timestamp of the process that created the lock.

You can inspect it with:

cat /home/node/.openclaw/plugin-runtime-deps/openclaw-2026.4.26-f53b52ad6d21/.openclaw-runtime-mirror.lock/owner.json

Then check if that PID is alive:

ps -fp <PID>
#

If no OpenClaw/npm/update process is running, it’s safe to delete the lock directory:

rm -rf /home/node/.openclaw/plugin-runtime-deps/openclaw-2026.4.26-f53b52ad6d21/.openclaw-runtime-mirror.lock

It’s not user data. It’s a stale “someone is writing this cache” marker. The useful stuff is your config/auth/session data elsewhere, not this lock.

winter kiln
#

So it would ok to check if that directory exists and delete before restarting openclaw?

granite cedarBOT
#

Yes — with one important caveat: do it after stopping OpenClaw, before starting it again, not while it’s actively starting/installing deps.

Safe pattern:

openclaw gateway stop

LOCK="/home/node/.openclaw/plugin-runtime-deps/openclaw-$(openclaw --version)-f53b52ad6d21/.openclaw-runtime-mirror.lock"

if [ -d "$LOCK" ]; then
  echo "Removing stale lock: $LOCK"
  rm -rf -- "$LOCK"
fi

openclaw gateway start