facebook/flow · critical

failed to spawn server daemon: {}

Error message

failed to spawn server daemon: {}

What it means

When the flow-server-monitor needs a server, it calls flow_server::server::daemonize() to spawn the Flow server daemon. Any Err from daemonize is panicked on with 'failed to spawn server daemon: {}'. daemonize fails most commonly on its lock check — 'There is already a server running for <root>' — but the same path carries log-open and temp-dir failures, so read the formatted error text for the true cause.

Source

Thrown at rust_port/crates/flow_server_monitor/src/flow_server_monitor_server.rs:698

                .unwrap_or_default()
                .as_nanos()
                & 0xFFFFFFFFFFFFFFFFu128
        );
        let server_options_arc = std::sync::Arc::new(_server_options.clone());

        let server_handle = flow_server::server::daemonize(
            &init_id,
            _log_file,
            _argv,
            lazy_mode.clone(),
            *no_flowlib,
            *ignore_version,
            file_watcher_pid.map(|p| p as u32),
            start_cause,
            server_options_arc,
            &monitor_options.cli_overrides,
        )
        .unwrap_or_else(|e| panic!("failed to spawn server daemon: {}", e));
        let pid: i32 = server_handle.child.id() as i32;
        // Cross-platform: `TcpStream::try_clone` duplicates the socket on
        // both Unix and Windows. The previous code used
        // `nix::unistd::dup(BorrowedFd)`, which is Unix-only.
        let in_stream = flow_daemon::descr_of_in_channel(&server_handle.channels.0)
            .try_clone()
            .expect("failed to dup server->monitor channel");
        let out_stream = flow_daemon::descr_of_out_channel(&server_handle.channels.1)
            .try_clone()
            .expect("failed to dup monitor->server channel");
        let daemon_handle = Arc::new(Mutex::new(Some(server_handle)));
        let close_daemon_handle = daemon_handle.clone();
        let close = move || {
            let mut guard = match close_daemon_handle.lock() {
                Ok(guard) => guard,
                Err(poisoned) => poisoned.into_inner(),
            };
            if let Some(handle) = guard.as_mut() {

View on GitHub (pinned to f88ac94bcf)

Solutions

  1. Stop the existing server for that root first (flow stop, or remove the lock file under the flow temp dir) and retry the monitor start.
  2. Read the text after the colon — it is daemonize's own message and names the actual failure ('already a server running', log open failure, missing entry point).
  3. Fix temp-dir/log permissions if that is the reported cause.
  4. If it fails on every start, wipe the stale lock and log files under <temp_dir>/flow for that root.

Example fix

# before: second server start on the same root
flow monitor-start ...  # panic: failed to spawn server daemon: Error: There is already a server running for /repo

# after
flow stop && flow monitor-start ...
Defensive patterns

Strategy: retry

Validate before calling

# before starting the monitor, ensure no server holds the lock for this root
flow status --root "$ROOT" >/dev/null 2>&1 && flow stop --root "$ROOT"
rm -f "$TMPDIR/flow/$(root_hash "$ROOT")/lock" 2>/dev/null || true

Try / catch

# pseudo-code for a supervisor
for attempt in 1 2; do
  flow monitor-start ... && break
  # panic text names the cause: 'already a server running' -> recycle
  flow stop 2>/dev/null || rm -f "$FLOW_TMP/lock"
  sleep 1
done

Prevention

When it happens

Trigger: Starting a monitor while another server already holds the lock for the same root+flowconfig combination; temp dir or log file setup failing inside daemonize (the log-file open error propagates here); the registered entry-point binary missing or not executable.

Common situations: Two IDEs/tools starting Flow on the same project concurrently; a previous daemon that was never stopped; switching flowconfig_name while the old server still runs; permission changes in the temp dir after the daemon user changed.

Related errors


AI-assisted analysis of facebook/flow@f88ac94bcf (2026-08-20). Data as JSON: /api/errors/8080933b9e59a141. Report an issue: GitHub.