nautechsystems/nautilus_trader · critical

Failed to determine hostname

Error message

Failed to determine hostname

What it means

Kernel initialization calls `sysinfo::System::host_name()` to derive a machine ID for the node. If the OS cannot provide a hostname (unusual for normal systems but possible in minimal containers), the Option is None and the kernel aborts startup with this anyhow error.

Source

Thrown at crates/system/src/kernel.rs:465

            if cmd.trader_id != trader_id {
                log::warn!("Received {cmd} not for this trader {trader_id}, ignoring");
                return;
            }

            if shutdown_requested.get() {
                log::debug!("Shutdown already requested, ignoring {cmd}");
                return;
            }

            log::info!("Received {cmd}, requesting shutdown");
            shutdown_requested.set(true);
        });
        let topic = MessagingSwitchboard::shutdown_system_topic();
        msgbus::subscribe_any(topic.into(), handler, None);
    }

    fn determine_machine_id() -> anyhow::Result<String> {
        sysinfo::System::host_name().ok_or_else(|| anyhow::anyhow!("Failed to determine hostname"))
    }

    fn initialize_logging(
        trader_id: TraderId,
        instance_id: UUID4,
        config: LoggerConfig,
    ) -> anyhow::Result<LogGuard> {
        #[cfg(feature = "tracing-bridge")]
        let use_tracing = config.use_tracing;

        let file_config = config.file_config.clone().unwrap_or_default();
        let log_guard = match init_logging(trader_id, instance_id, config, file_config) {
            Ok(guard) => guard,
            Err(e) => {
                // Only recover from SetLoggerError (logger already registered).
                // This is common in tests where multiple kernels are created and
                // the log crate's global logger persists after LogGuard teardown.
                // Any other error (e.g. thread spawn failure) is propagated.

View on GitHub (pinned to 18893faf8b)

Solutions

1. Set an explicit hostname for the container/host (e.g. `docker run --hostname nautilus ...` or `hostnamectl set-hostname`).
2. Ensure /etc/hostname and /proc/sys/kernel/hostname are present and readable in the environment.
3. Upgrade or fix sysinfo availability: verify the process can read /proc/sys/kernel/hostname (mount /proc in the container).
4. If embedding, call `Kernel::new` only after the environment is fully initialized.

Example fix

// before (Dockerfile)
FROM scratch
COPY nautilus_app /app
CMD ["/app"]

// after
FROM scratch
COPY nautilus_app /app
# give the container a resolvable hostname
CMD ["/app"]
# run with: docker run --hostname nautilus-trader-1 ...

import socket
hostname = socket.gethostname()
if not hostname:
    raise RuntimeError("Host has no hostname; set one before starting the kernel")

When it happens

Trigger: Calling `Kernel::new` (which runs `determine_machine_id`) on a host where `sysinfo::System::host_name()` returns None — e.g. a container without a set hostname, a chroot with missing /etc/hostname, or a stripped-down environment.

Common situations: Running nautilus_system inside minimal Docker/Kubernetes pods with unset `hostname`, scratch containers lacking /etc/hostname or /proc, or sandboxes with restricted /sys access.

Understand the failure class

Background: "environment variable is not set" and "Missing keys in environment" errors: what missing required env var messages mean and how to fix them — this error's family across 28 libraries.

Related errors

• Missing API credentials; set Deribit environment variables
• incomplete Lighter credentials: set {api_key_var}, {api_secr
• environment variable '{key}' must be set
• environment variable '{key}' is not valid Unicode
• LiveNode cannot be used with Backtest environment

AI-assisted analysis of nautechsystems/nautilus_trader@18893faf8b (2026-09-08). Data as JSON: /api/errors/45170acc2180a8cc. Report an issue: GitHub.