influxdata/influxdb · error · std::io::Error

{underlying available_parallelism error}

Error message

{underlying available_parallelism error}

What it means

When no explicit worker-thread count is configured, the runtime builder uses std::thread::available_parallelism() to size the Tokio worker pool. If the OS refuses to report parallelism, the error is wrapped in an io::Error and propagated, aborting runtime construction.

Solutions

1. Set an explicit worker-thread count (e.g. num_threads / INFLUXDB3 number-of-worker-threads style config) so available_parallelism is never consulted.
2. Fix the execution environment so the OS exposes CPU count (unmask /proc, adjust container constraints).
3. Inspect the wrapped underlying error to identify why the OS could not report parallelism and address that platform issue.

Example fix

// before
let runtime = tokio::Runtime::new()?; // relies on available_parallelism
// after
let rt = builder(worker_threads(8)) // explicit count in runtime config
    .build()?;

// supply a fallback thread count when the OS cannot report parallelism
fn worker_threads(configured: Option<usize>) -> usize {
    configured
        .or_else(|| std::thread::available_parallelism().ok().map(|n| n.get()))
        .unwrap_or(4)
}

let num_threads = std::thread::available_parallelism()
    .map(|n| n.get())
    .unwrap_or_else(|e| {
        log::warn!("available_parallelism failed ({e}); defaulting to 4");
        4
    });

When it happens

Trigger: Creating the InfluxDB 3 Tokio runtime with num_threads unset on a system where available_parallelism() fails (e.g. cgroup/procfs metadata unavailable, restricted containers, exotic or unsupported platforms).

Common situations: Running in tightly sandboxed containers where /sys or /proc cpu info is masked; unusual OSes or seccomp profiles that block the syscalls used by available_parallelism.

Related errors

• blocking task join
• Could not find user's home directory
• disabling LIFO slot requires `tokio_unstable`
• environment variable
• Error initializing tokio runtime

AI-assisted analysis of influxdata/influxdb@06200ef96b (2026-09-19). Data as JSON: /api/errors/f9c4965750d547e3. Report an issue: GitHub.

Appendix: source

Thrown at influxdb3_clap_blocks/src/tokio.rs:195

                        }
                    };

                    // enable subsystems
                    // - always enable timers
                    builder.enable_time();
                    builder.enable_io();

                    // set up proper thread names
                    let thread_counter = Arc::new(AtomicUsize::new(1));
                    let name = name.to_owned();
                    builder.thread_name_fn(move || {
                        format!("InfluxDB 3 Core Tokio {} {}", name, thread_counter.fetch_add(1, Ordering::SeqCst))
                    });

                    // worker thread count
                    let num_threads = match self.num_threads {
                        None => std::thread::available_parallelism()
                            .map_err(|e| std::io::Error::new(std::io::ErrorKind::Other, e))?,
                        Some(n) => n,
                    };
                    builder.worker_threads(num_threads.get());

                    if self.disable_lifo == Some(true) {
                        #[cfg(tokio_unstable)]
                        {
                            builder.disable_lifo_slot();
                        }
                        #[cfg(not(tokio_unstable))]
                        {
                            return Err(std::io::Error::new(
                                std::io::ErrorKind::Other,
                                "disabling LIFO slot requires `tokio_unstable`",
                            ));
                        }
                    }

View on GitHub (pinned to 06200ef96b)