linera-io/linera-protocol · critical

store

Error message

store

What it means

`RocksDbDatabase::maybe_create_and_connect` opens (or creates) the RocksDB database at the configured --path and connects to the namespace. RocksDB takes an exclusive file lock (LOCK) on its directory, so a concurrent opener fails immediately; other failures are I/O errors (missing or unwritable directory, full disk) or namespace/option errors. The `.expect("store")` in the storage server's main turns any Err into a startup panic, so the service never binds its endpoint.

Source

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

                statistics_level: Default::default(),
            };
            let storage_cache_config = StorageCacheConfig {
                max_cache_size,
                max_value_entry_size,
                max_find_keys_entry_size,
                max_find_key_values_entry_size,
                max_cache_entries,
                max_cache_value_size,
                max_cache_find_keys_size,
                max_cache_find_key_values_size,
            };
            let config = RocksDbStoreConfig {
                inner_config,
                storage_cache_config,
            };
            let database = RocksDbDatabase::maybe_create_and_connect(&config, &namespace)
                .await
                .expect("store");
            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

View on GitHub (pinned to 6c226ddcb3)

Solutions

1. Check for another process holding the DB: `fuser -v <path>/LOCK` or `lsof +D <path>`; stop it, or give the second instance a different --path
2. Verify the directory exists and is writable by the service user (mkdir -p; chown/chmod)
3. Check disk space with `df -h` — RocksDB cannot create files on a full volume
4. Only after confirming no process is running, remove the stale <path>/LOCK and guard file, then retry

Example fix

# before: second server on the same DB path -> panic "store"
linera-storage-service rocksdb --path /data/linera  --endpoint 127.0.0.1:9111 &
linera-storage-service rocksdb --path /data/linera  --endpoint 127.0.0.1:9112  # panics

# after: one instance per path
linera-storage-service rocksdb --path /data/linera-1 --endpoint 127.0.0.1:9111 &
linera-storage-service rocksdb --path /data/linera-2 --endpoint 127.0.0.1:9112

# before starting: is another instance already on this path?
fuser /data/linera/LOCK 2>/dev/null && { echo "DB in use - abort"; exit 1; }
mkdir -p /data/linera && [ -w /data/linera ] || { echo "path not writable"; exit 1; }

When it happens

Trigger: Launching `linera-storage-service rocksdb` twice with the same --path (the second instance hits RocksDB's LOCK and the PathWithGuard guard file); pointing --path at a read-only or non-existent directory; running out of disk while RocksDB creates its files.

Common situations: A previous server instance still running, or a crashed one leaving lock files behind; two test shards sharing a DB path; the path on a network filesystem where file locking is unreliable; a systemd restart racing a lingering old process.

Related errors

• Failed to open store
• Cannot apply default storage because the feature 'rocksdb' w
• Not possible to work with RocksDB
• Failed to parse {spawn_mode_name} as a spawn_mode
• Failed to set up SIGINT handler

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