linera-io/linera-protocol · critical

Failed to read server config

Error message

Failed to read server config

What it means

Before running a shard, the server derives its log file name from the validator public key, which requires reading the server config with util::read_json(server_config_path).expect("Failed to read server config"). The panic occurs during log-name computation when the config file is missing, unreadable, or not valid ValidatorServerConfig JSON — the process dies before any worker starts.

Source

Thrown at linera-service/src/server.rs:771

fn otlp_exporter_endpoint_for(command: &ServerCommand) -> Option<&str> {
    match command {
        ServerCommand::Run {
            otlp_exporter_endpoint,
            ..
        } => otlp_exporter_endpoint.as_deref(),
        ServerCommand::Generate { .. } | ServerCommand::EditShards { .. } => None,
    }
}

fn log_file_name_for(command: &ServerCommand) -> Cow<'static, str> {
    match command {
        ServerCommand::Run {
            shard,
            server_config_path,
            ..
        } => {
            let server_config: ValidatorServerConfig =
                util::read_json(server_config_path).expect("Failed to read server config");
            let public_key = &server_config.validator.public_key;

            if let Some(shard) = shard {
                format!("validator-{public_key}-shard-{shard}")
            } else {
                format!("validator-{public_key}")
            }
            .into()
        }
        ServerCommand::Generate { .. } | ServerCommand::EditShards { .. } => "server".into(),
    }
}

async fn run(options: ServerOptions) {
    linera_service::tracing::opentelemetry::init(
        &log_file_name_for(&options.command),
        otlp_exporter_endpoint_for(&options.command),
    );

View on GitHub (pinned to 6c226ddcb3)

Solutions

1. Verify the config path exists and is readable (ls -l, absolute path preferred)
2. Validate JSON syntax and structure with jq against a known-good ValidatorServerConfig
3. Regenerate the config with the current version's tooling before starting the shard
4. In orchestration, add a pre-flight check (test -f / jq -e .) that fails the unit with a clear message instead of a panic

Example fix

# before
linera server run --shard 0 --server-config-path server.json

# after
test -f /etc/linera/server.json && jq -e .validator.public_key /etc/linera/server.json
linera server run --shard 0 --server-config-path /etc/linera/server.json

# Validate before launch.
CONF=/etc/linera/server.json
test -r "$CONF" && jq -e '.validator.public_key' "$CONF" >/dev/null \
  || { echo "server config missing/invalid: $CONF" >&2; exit 1; }
linera server run --shard 0 --server-config-path "$CONF"

When it happens

Trigger: Running `linera server run --server-config-path <path>` where <path> does not exist, has bad permissions, holds malformed JSON, or a schema that no longer deserializes into ValidatorServerConfig.

Common situations: Deploying a new validator shard without first creating its server config; upgrading Linera so the config schema changed; container images where the config mount is missing; path typos in launch scripts.

Related errors

• Fail to read server config
• Invalid options file format: \n {options_string}
• invalid block export configuration
• Invalid RUST_LOG_FORMAT: `{format}`. Valid values are `json
• test-log: RUST_LOG_SPAN_EVENTS must contain filters separate

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