Bug

On minimal Debian/Ubuntu/Alpine systems without lsof (default state for many container/cloud images), gateway startup logs:

lsof failed during initial stale-pid scan for port 18789: ENOENT

Source: dist/restart-stale-pids-Bk1dgWU7.js (search for "lsof failed during initial stale-pid scan").

Impact

Cosmetic — gateway still starts (presumably falls back to /proc or netstat). But the WARN is misleading: lsof failed reads as "lsof tried and errored", when really lsof was never installed.

Repro

1. Fresh Debian 11/12 minimal install (no lsof package)
2. Install OpenClaw v2026.5.2
3. Start gateway
4. WARN appears in log within first 5s

Proposed fix

Before invoking lsof, check whether the binary exists:

import { which } from "node:child_process"; // or use which package
const lsofPath = await which("lsof").catch(() => null);
if (!lsofPath) {
  // skip lsof phase silently; fall through to /proc/netstat scan
  return;
}
// existing lsof logic

Or rewrite the catch block to differentiate ENOENT (binary missing) from other errors:

catch (err) {
  if (err.code === "ENOENT") {
    // lsof binary not installed — falling back is expected
    restartLog.debug("lsof not available, using fallback stale-pid scan");
    return;
  }
  restartLog.warn(`lsof failed during initial stale-pid scan for port ${port}: ${err.message}`);
}

Test plan

1. apt remove lsof (or run on minimal container)
2. Restart gateway
3. Confirm: no lsof failed WARN
4. Confirm: gateway still detects/clears stale PIDs via fallback

Affected files

• Source for dist/restart-stale-pids-Bk1dgWU7.js

Environment

• OpenClaw v2026.5.2 (8b2a6e5)
• Debian 11 (Bitnami AWS instance)
• Node 24.13.0
• Loopback-only gateway on port 18789