linera-io/linera-protocol · info

Failed to get local address

Error message

Failed to get local address

What it means

Immediately after a successful TcpListener::bind, start_metrics calls listener.local_addr() and expects success (linera-metrics/src/monitoring_server.rs:105). local_addr only fails if the socket is already closed, which cannot happen between a successful bind and this call. This expect is defensive boilerplate and is effectively unreachable in practice.

Source

Thrown at linera-metrics/src/monitoring_server.rs:105

/// `register_metrics` is the caller's `init_metrics`. It is a parameter rather than a direct
/// call because this crate sits below `linera-views` and friends in the dependency graph and
/// cannot reach their metrics; taking it here makes forgetting to register a compile error
/// instead of a metric that silently only appears once its code path first runs.
pub fn start_metrics(
    address: impl ToSocketAddrs + Debug + Send + 'static,
    shutdown_signal: CancellationToken,
    memory_profiling: MemoryProfiling,
    register_metrics: impl FnOnce(),
) {
    crate::runtime_metrics::register();
    register_metrics();
    let app = metrics_router(memory_profiling);

    tokio::spawn(async move {
        let listener = tokio::net::TcpListener::bind(address)
            .await
            .expect("Failed to bind to address");
        let address = listener.local_addr().expect("Failed to get local address");

        info!("Starting to serve metrics on {:?}", address);
        if let Err(e) = axum::serve(listener, app)
            .with_graceful_shutdown(shutdown_signal.cancelled_owned())
            .await
        {
            panic!("Error serving metrics: {e}");
        }
    });
}

fn metrics_router(memory_profiling: MemoryProfiling) -> Router {
    #[cfg(feature = "jemalloc")]
    if memory_profiling == MemoryProfiling::Enabled {
        match MemoryProfiler::check_prof_ctl() {
            Ok(()) => {
                info!("Memory profiling enabled, registering /debug/pprof and /debug/flamegraph endpoints");
                return Router::new()

View on GitHub (pinned to 6c226ddcb3)

Solutions

1. Treat a hit of this panic as a bug report: capture the backtrace and file it against linera-metrics.
2. Restart the affected service; this is not caused by ports, config, or load.

When it happens

Trigger: No realistic trigger: it would require the listener to be closed between bind() and local_addr() within the same async block, which standard tokio usage cannot produce.

Common situations: None - if this message appears, it points to memory corruption or an exotic runtime fault, not to configuration or usage.

Related errors

• Unexpected response type
• owner should be different from spender
• invalid block export configuration: {message}
• Expected an `ExecutionError`. Got: {self:#?}
• Expected an `ExecutionError`. Got: {chain_error:#?}

AI-assisted analysis of linera-io/linera-protocol@6c226ddcb3 (2026-08-22). Data as JSON: /api/errors/b62a541466376455. Report an issue: GitHub.