What causes "a successful running of the server" in linera-io/linera-protocol?

Find and stop the holder: `ss -ltnp | grep ` or `lsof -i : `, then restart — or pass a different --endpoint

a successful running of the server

Error message

a successful running of the server

What it means

`Server::builder().add_service(StorageServiceServer::new(store)).serve(endpoint)` runs the tonic gRPC server on the endpoint parsed from the CLI. The future resolves with Err when the listener cannot be bound — port already in use, permission denied on a privileged port, unusable address — or when serving hits a fatal I/O error. `.expect("a successful running of the server")` panics in main, so the storage service process exits.

Source

Thrown at linera-storage-service/src/server.rs:712

            let store = database.open_shared(&[]).expect("Failed to open store");
            let store = LocalStore::RocksDb(store);
            (store, endpoint)
        }
    };
    let pending_big_puts = Arc::new(RwLock::new(BTreeMap::default()));
    let pending_big_reads = Arc::new(RwLock::new(PendingBigReads::default()));
    let store = StorageServer {
        store,
        pending_big_puts,
        pending_big_reads,
    };
    let endpoint = endpoint.parse().unwrap();
    info!("Starting linera_storage_service on endpoint={}", endpoint);
    Server::builder()
        .add_service(StorageServiceServer::new(store))
        .serve(endpoint)
        .await
        .expect("a successful running of the server");
}

View on GitHub (pinned to 6c226ddcb3)

Solutions

Find and stop the holder: `ss -ltnp | grep <port>` or `lsof -i :<port>`, then restart — or pass a different --endpoint
Use an unprivileged port (>= 1024), or run with the privileges required for the chosen port
Confirm the previous instance fully exited (`ps aux | grep linera-storage-service`) before restarting

Example fix

# before
linera-storage-service rocksdb --endpoint 127.0.0.1:9111 ...  # port taken -> panic

# after
ss -ltnp | grep 9111   # identify the holder; stop it or pick a free port
linera-storage-service rocksdb --endpoint 127.0.0.1:9112 ...

Defensive patterns

Strategy: validation

Validate before calling

// Rust: pre-flight the port before building the server
let addr: std::net::SocketAddr = endpoint.parse()?;
if let Err(e) = std::net::TcpListener::bind(addr) {
    eprintln!("endpoint {addr} unavailable: {e}");
    std::process::exit(1);
}

Prevention

Assign each service and test a distinct endpoint from a known-free range
Add a bind pre-flight (TcpListener::bind) to startup scripts
In tests, bind port 0 and read back the OS-assigned port instead of hardcoding

When it happens

Trigger: Starting linera-storage-service on an --endpoint whose port is already bound by another process; binding a port below 1024 without privileges; restarting immediately while the old process still holds the socket.

Common situations: Two instances configured with the same endpoint; a previous crashed instance's socket lingering; test harnesses racing to grab the same port; container port-mapping conflicts.

Related errors

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