influxdata/influxdb · error · VenvError

Error shelling out

Error message

Error shelling out: {0}

What it means

`VenvError::CommandError` wraps a `std::io::Error` produced when the code shells out to Python (e.g. running `pip install` inside the virtualenv). It surfaces OS-level failures such as the process failing to spawn or a non-spawnable executable.

Solutions

  1. Check that the python executable inside the venv exists and is executable (`ls -l <venv>/bin/python`).
  2. Recreate the virtualenv if its base interpreter was removed or upgraded.
  3. Run the server with sufficient permissions and a writable filesystem for the venv.
  4. Inspect the wrapped io::Error (its source chain) for the OS-level cause (ENOENT, EACCES, etc.).

Example fix

// before
Command::new(venv_python).args(["-m", "pip", "install", pkg]).output()?;
// after
let out = Command::new(&venv_python).args(["-m", "pip", "install", pkg]).output()
    .map_err(VenvError::CommandError)
    .context(format!("python binary missing at {}", venv_python.display()))?;
Defensive patterns

Strategy: try-catch

Validate before calling

// Before invoking plugin loading
let venv_python = Path::new(&venv_dir).join("bin/python");
if !venv_python.exists() || !is_executable(&venv_python) { /* recreate venv first */ }

Try / catch

// Rust caller
match venv.install_packages(&pkgs) {
    Err(VenvError::CommandError(io)) => {
        eprintln!("subprocess failed: {io} (source: {:?})", io.source());
        // check venv python exists, permissions, PATH
    }
    other => other?,
}

Prevention

When it happens

Trigger: Running virtualenv package installation (`run_pip_install`-style commands) where spawning the python subprocess fails: python binary path invalid, permissions missing, or working directory/paths bad.

Common situations: Venv created with a python binary later deleted or moved; PATH stripped in containerized deployments; read-only filesystem preventing pip operations; SELinux/apparmor blocking exec.

Related errors


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

Appendix: source

Thrown at influxdb3_processing_engine/src/virtualenv.rs:15

use observability_deps::tracing::debug;
use pyo3::Python;
use std::env;
use std::ffi::CString;
use std::path::{Path, PathBuf};
use std::sync::Once;
use thiserror::Error;

static PYTHON_INIT: Once = Once::new();

#[derive(Error, Debug)]
pub enum VenvError {
    #[error("Failed to initialize virtualenv: {0}")]
    InitError(String),
    #[error("Error shelling out: {0}")]
    CommandError(#[from] std::io::Error),
}

// Find the python installation location (not virtual env).
// XXX: use build flag?
fn find_python_install() -> Option<PathBuf> {
    let influxdb3_exe = env::current_exe().unwrap();
    let influxdb3_exe_dir = influxdb3_exe.parent().unwrap();
    let influxdb3_rel_dir = influxdb3_exe_dir.join("python");
    let influxdb3_linux_dir = influxdb3_exe_dir.join("../lib/influxdb3/python");

    let python_inst = if cfg!(target_os = "linux")
        && (influxdb3_exe_dir == Path::new("/usr/bin")
            || influxdb3_exe_dir == Path::new("/usr/local/bin"))
        && influxdb3_linux_dir.is_dir()
    {
        // Official Linux deb/rpm/docker builds are in /usr (but also allow for
        // /usr/local) so use runtime in /usr/[local/]lib/influxdb3/python/

View on GitHub (pinned to 06200ef96b)