ruvnet/ruflo · error

Meta-Proxy port owner pid ${owner.pid} is not a recognized R

Error message

Meta-Proxy port owner pid ${owner.pid} is not a recognized Ruflo/MetaHarness binary; refusing to signal it.

What it means

Before upgrading, installAndActivateProxy() stops the daemon that currently owns the proxy port. stopEffective() first identifies the port owner's executable and only signals it if the executable matches a known Ruflo/MetaHarness meta-proxy path (proxyBinaryPath, ~/.metaharness/..., ~/.cargo/bin/meta-proxy). If the pid owning the port is any other binary, the library refuses to SIGTERM it to avoid killing an unrelated process.

Source

Thrown at v3/@claude-flow/cli/src/proxy/activation.ts:113

      try {
        const age = Date.now() - fs.statSync(lock).mtimeMs;
        const owner = Number.parseInt(fs.readFileSync(path.join(lock, 'owner'), 'utf8').trim(), 10);
        if (age > 120_000 && (!Number.isSafeInteger(owner) || owner <= 0 || !processExists(owner))) {
          fs.rmSync(lock, { recursive: true, force: true });
          continue;
        }
      } catch { /* another installer may still be writing its owner */ }
      await wait(50);
    }
  }
  throw new Error('Another Ruflo/MetaHarness installer still owns the Meta-Proxy install lease.');
}

async function stopEffective(wait: Wait): Promise<EffectiveProxy | null> {
  const owner = await probeEffectiveProxy();
  if (!owner) return null;
  if (!isSupportedOwner(owner.executable, process.platform)) {
    throw new Error(`Meta-Proxy port owner pid ${owner.pid} is not a recognized Ruflo/MetaHarness binary; refusing to signal it.`);
  }
  process.kill(owner.pid, 'SIGTERM');
  for (let attempt = 0; attempt < 40; attempt++) {
    await wait(50);
    const current = await probeEffectiveProxy();
    if (!current || current.pid !== owner.pid) return owner;
  }
  throw new Error(`Stale Meta-Proxy pid ${owner.pid} did not stop.`);
}

function launch(binary: string): number {
  fs.mkdirSync(path.dirname(proxyLogFilePath()), { recursive: true, mode: 0o700 });
  const log = fs.openSync(proxyLogFilePath(), 'a', 0o600);
  try {
    const child = spawn(binary, [], { detached: true, stdio: ['ignore', log, log], windowsHide: true });
    if (!child.pid) throw new Error('Meta-Proxy did not return a process id.');
    child.unref();
    fs.writeFileSync(proxyPidFilePath(), `${child.pid}\n`, { mode: 0o600 });

View on GitHub (pinned to 29f048fc3b)

Solutions

  1. Identify what owns the port (lsof -i :11435 or ss -ltnp) and stop that unrelated service yourself
  2. Move/reinstall meta-proxy to one of the recognized paths (proxyBinaryPath, ~/.metaharness/bin, ~/.metaharness/meta-proxy/bin, or ~/.cargo/bin) and restart it so isSupportedOwner() matches
  3. Change the Meta-Proxy port in the proxy config to a free port and retry the install
  4. If you control the source, extend the allowed executable list in isSupportedOwner() to include your custom install path

Example fix

// before: custom location
/home/me/tools/meta-proxy        # not recognized, error
// after: recognized location
mv /home/me/tools/meta-proxy ~/.cargo/bin/meta-proxy
Defensive patterns

Strategy: validation

Validate before calling

// Probe what owns the port before installing; only proceed if it's ours or free.
import { createConnection } from 'node:net';
const portFree = await new Promise<boolean>(res => {
  const s = createConnection(11435, '127.0.0.1');
  s.on('connect', () => { s.destroy(); res(false); });
  s.on('error', () => res(true));
});
if (!portFree) console.log('Port 11435 busy — confirm it is a recognized meta-proxy before installing');

Type guard

null

Try / catch

try {
  await installAndActivateProxy(version);
} catch (e) {
  if (e instanceof Error && e.message.includes('not a recognized Ruflo/MetaHarness binary')) {
    // surface which pid/path owns the port and stop the foreign service first
    console.error(e.message, '— run: lsof -i :11435');
  } else throw e;
}

Prevention

When it happens

Trigger: Calling installAndActivateProxy() while the configured port (default 11435) is occupied by a process that is not one of the recognized meta-proxy binaries — e.g. a different service bound to the same port, a self-compiled meta-proxy in a non-standard path, or a renamed copy.

Common situations: Another dev tool (or a manually started meta-proxy from a nonstandard location) already listens on 11435; users moved/renamed the binary; custom install locations not in the allowed list; a container port mapping colliding with the host port.

Related errors


AI-assisted analysis of ruvnet/ruflo@29f048fc3b (2026-09-01). Data as JSON: /api/errors/cb3818b589354b0e. Report an issue: GitHub.