What causes "Failed to generate random bytes!" in atuinsh/atuin?

Allow the getrandom (and where relevant getentropy) syscalls in the container/seccomp policy

Failed to generate random bytes!

Error message

Failed to generate random bytes!

What it means

crypto_random_bytes() fills a buffer via getrandom::fill, which draws from the OS CSPRNG (getrandom(2) on Linux, getentropy on macOS/BSD, BCryptGenRandom on Windows). fill returns Err only when the operating system cannot provide secure randomness at all; atuin treats that as unrecoverable and panics. This helper backs key and session-id generation (e.g. share spawn ids, encryption key material paths), so the failure is fatal by design.

Source

Thrown at crates/atuin-common/src/utils.rs:17

use std::env;
use std::ffi::OsString;
use std::path::{Path, PathBuf};

use eyre::{Result, eyre};

use base64::prelude::{BASE64_URL_SAFE_NO_PAD, Engine};
use getrandom::fill;
use uuid::Uuid;

/// Generate N random bytes, using a cryptographically secure source
pub fn crypto_random_bytes<const N: usize>() -> [u8; N] {
    // rand say they are in principle safe for crypto purposes, but that it is perhaps a better
    // idea to use getrandom for things such as passwords.
    let mut ret = [0u8; N];

    fill(&mut ret).expect("Failed to generate random bytes!");

    ret
}

/// Generate N random bytes using a cryptographically secure source, return encoded as a string
pub fn crypto_random_string<const N: usize>() -> String {
    let bytes = crypto_random_bytes::<N>();

    // We only use this to create a random string, and won't be reversing it to find the original
    // data - no padding is OK there. It may be in URLs.
    BASE64_URL_SAFE_NO_PAD.encode(bytes)
}

pub fn uuid_v7() -> Uuid {
    Uuid::now_v7()
}

pub fn uuid_v4() -> String {

View on GitHub (pinned to 202f6ad98e)

Solutions

Allow the getrandom (and where relevant getentropy) syscalls in the container/seccomp policy
Use a Linux 3.17+ kernel or a modern base image so the OS RNG is available
Ensure /dev/urandom exists and is readable in minimal containers
For entropy-starved VMs, add an entropy source (virtio-rng) or delay atuin startup until the CRNG is seeded

Defensive patterns

Strategy: validation

Validate before calling

fn os_rng_available() -> bool {
    getrandom::fill(&mut [0u8; 8]).is_ok()
}

if !os_rng_available() {
    eprintln!("OS secure RNG unavailable; fix the sandbox/kernel before using atuin");
    std::process::exit(1);
}

Try / catch

match std::panic::catch_unwind(|| atuin_common::utils::crypto_random_string::<32>()) {
    Ok(token) => token,
    Err(_) => {
        // RNG failure is fatal; never fall back to weak randomness
        eprintln!("OS RNG unavailable (blocked getrandom? old kernel? unseeded CRNG?)");
        std::process::exit(1);
    }
}

Prevention

Audit seccomp/AppArmor/gVisor policies for getrandom/getentropy before deploying atuin into sandboxes
Smoke-test one crypto_random_string call at startup so failures surface with a clear message
Never catch this panic and substitute a non-CSPRNG source

When it happens

Trigger: Calling crypto_random_bytes/crypto_random_string where the OS RNG is unreachable: a seccomp or container policy blocking the getrandom/getentropy syscall, a kernel older than Linux 3.17 with no usable /dev/urandom, extremely early boot before the kernel CRNG is seeded, or a stripped container image missing /dev/urandom.

Common situations: Custom Docker seccomp profiles, gVisor/Kata configurations, or AppArmor rules denying getrandom(2); ancient kernels or minimal embedded targets; hardened images mounting an empty /dev.

Related errors

AI-assisted analysis of atuinsh/atuin@202f6ad98e (2026-08-16). Data as JSON: /api/errors/6c62357005c82d16. Report an issue: GitHub.