Problem

Port conflict diagnostics use lsof -nP -iTCP:PORT -sTCP:LISTEN to identify what process owns a port. When lsof is not installed (common on minimal Linux servers, containers, and cloud VMs), the fallback is a generic socket bind test that reports "Port is in use but process details are unavailable (install lsof or run as an admin user)."

Impact

Users get unhelpful diagnostics on minimal Linux installs. They know the port is busy but not what is using it — the most critical piece of information for debugging.

Suggested Fix

Fall back to ss -tlnp which is part of iproute2 — installed on virtually every Linux system:

async function readUnixListeners(port) {
  // Try lsof first
  const lsofResult = await tryLsof(port);
  if (lsofResult.listeners.length > 0) return lsofResult;
  
  // Fallback: ss (iproute2, nearly universal on Linux)
  if (process.platform === "linux") {
    const ssResult = await runCommandSafe(["ss", "-tlnp", `sport = :${port}`]);
    if (ssResult.code === 0) {
      return parseSsOutput(ssResult.stdout, port);
    }
  }
  
  return lsofResult; // return whatever lsof gave us
}

ss output includes PID and process name, providing the same diagnostic value as lsof.

Where in Code

• dist/chrome-*.js — readUnixListeners() function, LSOF_CANDIDATES constant

Environment

• OpenClaw v2026.2.9
• Linux without lsof installed