[GH-ISSUE #348] Librespot fails to startup due to missing entropy

kerem commented

2026-02-27 19:29:32 +03:00

Owner

Originally created by @matthijskooijman on GitHub (Jul 13, 2019).
Original GitHub issue: https://github.com/librespot-org/librespot/issues/348

I've found that librespot under Max2play on a rpi sometimes fails to start at system boot. At least a few times, I've captured a backtrace (on a Zero W) of this behaviour, which suggests that there is insufficient entropy available in the system, causing startup to fail. Restarting it manually fixes it, though I've seen that it fails again until a few minutes later when (I guess) more entropy is available.

The actual problem is of course beyond librespot's control, but I wonder if librespot could perhaps switch to a different random generated (e.g. urandom vs random, though it might be already using getrandom which AFAIU returns random values without consuming extra entropy, provided some startup entropy is available, which probably best of both).

Alternatively, librespot could perhaps wait and retry until sufficient entropy is available? That would at least allow unattended startup to complete, even after some time.

Here's the backtrace:

thread 'main' panicked at 'could not initialize thread_rng: All entropy sources failed (permanently unavailable); cause: getrandom not ready (not ready yet); c
stack backtrace:
   0:   0x9e137c - backtrace::backtrace::libunwind::trace::hb317fd79f338e9ac
                       at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.29/src/backtrace/libunwind.rs:88
   1:   0x9e137c - backtrace::backtrace::trace_unsynchronized::h577e08d87958ca80
                       at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.29/src/backtrace/mod.rs:66
   2:   0x9e137c - std::sys_common::backtrace::_print::hbfee0f6c5053d54e
                       at src/libstd/sys_common/backtrace.rs:47
   3:   0x9e137c - std::sys_common::backtrace::print::he0aac2b05fe6a451
                       at src/libstd/sys_common/backtrace.rs:36
   4:   0x9e137c - std::panicking::default_hook::{{closure}}::ha2ef00deb6db7a83
                       at src/libstd/panicking.rs:200
   5:   0x9e0f2c - std::panicking::default_hook::h641d7e1cec244c78
                       at src/libstd/panicking.rs:214
   6:   0x9e1b40 - std::panicking::rust_panic_with_hook::h4043fa8d29430a82
                       at src/libstd/panicking.rs:477
   7:   0x9e1704 - std::panicking::continue_panic_fmt::h69e00c7989848347
                       at src/libstd/panicking.rs:384
   8:   0x9e1654 - std::panicking::begin_panic_fmt::h49ff18ea78dc8817
                       at src/libstd/panicking.rs:339
   9:   0x9364c8 - rand::rngs::thread::THREAD_RNG_KEY::__init::{{closure}}::heeae17905a9999de
  10:   0x936260 - std::thread::local::lazy::LazyKeyInner<T>::initialize::h635d7ef8d9fcd6be
  11:   0x936f08 - std::thread::local::fast::Key<T>::try_initialize::hd4fc2756117a8f1a
  12:   0x936e94 - rand::rngs::thread::thread_rng::h471381a5136d3362
  13:   0x5215dc - librespot_connect::discovery::discovery::h45c1c14a868774ea
  14:   0x4f6a5c - librespot::main::h17b86eb414fa277e
  15:   0x4d13dc - std::rt::lang_start::{{closure}}::he764af215f6d223f
  16:   0x9e1568 - std::rt::lang_start_internal::{{closure}}::hfac715f2e0a14136
                       at src/libstd/rt.rs:49
  17:   0x9e1568 - std::panicking::try::do_call::h5bd3d572724ac2e1
                       at src/libstd/panicking.rs:296
  18:   0x9e8b18 - __rust_maybe_catch_panic
                       at src/libpanic_unwind/lib.rs:82
  19:   0x9e1fd0 - std::panicking::try::h3203ccbd3c7c13af
                       at src/libstd/panicking.rs:275
  20:   0x9e1fd0 - std::panic::catch_unwind::hd9cff17009151b9a
                       at src/libstd/panic.rs:394
  21:   0x9e1fd0 - std::rt::lang_start_internal::hab130c51c66092b9
                       at src/libstd/rt.rs:48
  22:   0x4f794c - main
  23: 0xb6e58678 - __libc_start_main

Originally created by @matthijskooijman on GitHub (Jul 13, 2019). Original GitHub issue: https://github.com/librespot-org/librespot/issues/348 I've found that librespot under Max2play on a rpi sometimes fails to start at system boot. At least a few times, I've captured a backtrace (on a Zero W) of this behaviour, which suggests that there is insufficient entropy available in the system, causing startup to fail. Restarting it manually fixes it, though I've seen that it fails again until a few minutes later when (I guess) more entropy is available. The actual problem is of course beyond librespot's control, but I wonder if librespot could perhaps switch to a different random generated (e.g. `urandom` vs `random`, though it *might* be already using `getrandom` which AFAIU returns random values without consuming extra entropy, provided some startup entropy is available, which probably best of both). Alternatively, librespot could perhaps wait and retry until sufficient entropy *is* available? That would at least allow unattended startup to complete, even after some time. Here's the backtrace: ``` thread 'main' panicked at 'could not initialize thread_rng: All entropy sources failed (permanently unavailable); cause: getrandom not ready (not ready yet); c stack backtrace: 0: 0x9e137c - backtrace::backtrace::libunwind::trace::hb317fd79f338e9ac at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.29/src/backtrace/libunwind.rs:88 1: 0x9e137c - backtrace::backtrace::trace_unsynchronized::h577e08d87958ca80 at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.29/src/backtrace/mod.rs:66 2: 0x9e137c - std::sys_common::backtrace::_print::hbfee0f6c5053d54e at src/libstd/sys_common/backtrace.rs:47 3: 0x9e137c - std::sys_common::backtrace::print::he0aac2b05fe6a451 at src/libstd/sys_common/backtrace.rs:36 4: 0x9e137c - std::panicking::default_hook::{{closure}}::ha2ef00deb6db7a83 at src/libstd/panicking.rs:200 5: 0x9e0f2c - std::panicking::default_hook::h641d7e1cec244c78 at src/libstd/panicking.rs:214 6: 0x9e1b40 - std::panicking::rust_panic_with_hook::h4043fa8d29430a82 at src/libstd/panicking.rs:477 7: 0x9e1704 - std::panicking::continue_panic_fmt::h69e00c7989848347 at src/libstd/panicking.rs:384 8: 0x9e1654 - std::panicking::begin_panic_fmt::h49ff18ea78dc8817 at src/libstd/panicking.rs:339 9: 0x9364c8 - rand::rngs::thread::THREAD_RNG_KEY::__init::{{closure}}::heeae17905a9999de 10: 0x936260 - std::thread::local::lazy::LazyKeyInner<T>::initialize::h635d7ef8d9fcd6be 11: 0x936f08 - std::thread::local::fast::Key<T>::try_initialize::hd4fc2756117a8f1a 12: 0x936e94 - rand::rngs::thread::thread_rng::h471381a5136d3362 13: 0x5215dc - librespot_connect::discovery::discovery::h45c1c14a868774ea 14: 0x4f6a5c - librespot::main::h17b86eb414fa277e 15: 0x4d13dc - std::rt::lang_start::{{closure}}::he764af215f6d223f 16: 0x9e1568 - std::rt::lang_start_internal::{{closure}}::hfac715f2e0a14136 at src/libstd/rt.rs:49 17: 0x9e1568 - std::panicking::try::do_call::h5bd3d572724ac2e1 at src/libstd/panicking.rs:296 18: 0x9e8b18 - __rust_maybe_catch_panic at src/libpanic_unwind/lib.rs:82 19: 0x9e1fd0 - std::panicking::try::h3203ccbd3c7c13af at src/libstd/panicking.rs:275 20: 0x9e1fd0 - std::panic::catch_unwind::hd9cff17009151b9a at src/libstd/panic.rs:394 21: 0x9e1fd0 - std::rt::lang_start_internal::hab130c51c66092b9 at src/libstd/rt.rs:48 22: 0x4f794c - main 23: 0xb6e58678 - __libc_start_main ```

kerem closed this issue

2026-02-27 19:29:33 +03:00

kerem commented

2026-02-27 19:29:33 +03:00

Author

Owner

@matthijskooijman commented on GitHub (Jul 13, 2019):

One more note, this was with a self-compiled git master version (github.com/librespot-org/librespot@4e3576ba7c).

@matthijskooijman commented on GitHub (Jul 13, 2019): One more note, this was with a self-compiled git master version (https://github.com/librespot-org/librespot/commit/4e3576ba7c6146cf68e1953daeec929d619b26b1).

kerem commented

2026-02-27 19:29:33 +03:00

Author

Owner

@willstott101 commented on GitHub (Nov 2, 2019):

The error itself seems completely contradictory:

thread 'main' panicked at 'could not initialize thread_rng: All entropy sources failed (permanently unavailable); cause: getrandom not ready (not ready yet); c

The version you link doesn't have getrandom in Cargo.lock so must have been making the syscall from the rand crate. I suspect the use of the cross-platform getrandom crate, as rand does now will improve things.

As far as I can tell getrandom is supposed to block until it can get the requested bytes. And should only panic if it can't ever return random bytes - or is interrupted by the OS.

Have you seen this issue with a newer build of librespot?

@willstott101 commented on GitHub (Nov 2, 2019): The error itself seems completely contradictory: `thread 'main' panicked at 'could not initialize thread_rng: All entropy sources failed (`**`permanently unavailable`**`); cause: getrandom not ready (`**`not ready yet`**`); c` The version you link doesn't have `getrandom` in Cargo.lock so must have been making the syscall from the rand crate. I suspect the use of the cross-platform `getrandom` crate, as `rand` does now will improve things. As far as I can tell `getrandom` is supposed to block until it can get the requested bytes. And should only panic if it can't ever return random bytes - or is interrupted by the OS. Have you seen this issue with a newer build of librespot?

kerem commented

2026-02-27 19:29:33 +03:00

Author

Owner

@matthijskooijman commented on GitHub (Nov 2, 2019):

Have you seen this issue with a newer build of librespot?

I have not been using librespot since I reported this (I needed it for a specific event, I'm not using it daily currently).

@matthijskooijman commented on GitHub (Nov 2, 2019): > Have you seen this issue with a newer build of librespot? I have not been using librespot since I reported this (I needed it for a specific event, I'm not using it daily currently).

Rows
Columns

[GH-ISSUE #348] Librespot fails to startup due to missing entropy #231