Limits in systemd service example are too strict for huge boxes #4937

New Issue

GiteaMirror · 2026-03-07T20:07:26-06:00

GiteaMirror commented

2026-03-07 20:07:26 -06:00

Originally created by @jackyyf on GitHub (Jun 6, 2022).

Subject of the issue

Limits in systemd service example are too strict for huge boxes

Deployment environment

vaultwarden version: 1.25.0

Install method: built from source
Clients used: N/A
Reverse proxy and version: N/A
MySQL/MariaDB or PostgreSQL version: N/A
Other relevant details:
The server running vaultwarden is a Dual E5-2696v3, with 36 cores and 72 threads.

Steps to reproduce

Use the reference systemd service file in wiki https://github.com/dani-garcia/vaultwarden/wiki/Setup-as-a-systemd-service

Expected behaviour

Vaultwarden booted up.

Actual behaviour

Vaultwarden panicked with some strange tracebacks, logs attached.

Troubleshooting data

[2022-06-07 04:10:38.100][panic][ERROR] thread 'main' panicked at 'Cannot drop a runtime in a context where blocking is not allowed. This happens when a runtime is dropped from within an asynchronous context.': <redacted>/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.18.2/src/runtime/blocking/shutdown.rs:51
   0: vaultwarden::init_logging::{{closure}}
   1: std::panicking::rust_panic_with_hook
   2: std::panicking::begin_panic::{{closure}}
   3: std::sys_common::backtrace::__rust_end_short_backtrace
   4: std::panicking::begin_panic
   5: tokio::runtime::blocking::shutdown::Receiver::wait
   6: tokio::runtime::blocking::pool::BlockingPool::shutdown
   7: core::ptr::drop_in_place<tokio::runtime::blocking::pool::BlockingPool>
   8: core::ptr::drop_in_place<vaultwarden::schedule_jobs::{{closure}}::{{closure}}>
   9: core::ptr::drop_in_place<std::thread::Builder::spawn_unchecked_<vaultwarden::schedule_jobs::{{closure}}::{{closure}},()>::{{closure}}>
  10: std::sys::unix::thread::Thread::new
  11: std::thread::Builder::spawn
  12: vaultwarden::main::{{closure}}
  13: tokio::park::thread::CachedParkThread::block_on
  14: tokio::runtime::thread_pool::ThreadPool::block_on
  15: rocket::async_main
  16: vaultwarden::main
  17: std::sys_common::backtrace::__rust_begin_short_backtrace
  18: std::rt::lang_start::{{closure}}
  19: std::rt::lang_start_internal
  20: main
  21: __libc_start_main
  22: _start

Suggestion

Limit maximum threads for pool to something like 16 or 32 (instead of the default $(nproc)) would be a good choice :) I don't think our nice program would have such huge load that requires a bunch of threads to handle

Originally created by @jackyyf on GitHub (Jun 6, 2022).   ### Subject of the issue Limits in systemd service example are too strict for huge boxes ### Deployment environment     * vaultwarden version: 1.25.0  * Install method: built from source * Clients used: N/A * Reverse proxy and version: N/A * MySQL/MariaDB or PostgreSQL version: N/A * Other relevant details: The server running vaultwarden is a Dual E5-2696v3, with 36 cores and 72 threads. ### Steps to reproduce  Use the reference systemd service file in wiki https://github.com/dani-garcia/vaultwarden/wiki/Setup-as-a-systemd-service ### Expected behaviour Vaultwarden booted up. ### Actual behaviour Vaultwarden panicked with some strange tracebacks, logs attached. ### Troubleshooting data ``` [2022-06-07 04:10:38.100][panic][ERROR] thread 'main' panicked at 'Cannot drop a runtime in a context where blocking is not allowed. This happens when a runtime is dropped from within an asynchronous context.': <redacted>/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.18.2/src/runtime/blocking/shutdown.rs:51 0: vaultwarden::init_logging::{{closure}} 1: std::panicking::rust_panic_with_hook 2: std::panicking::begin_panic::{{closure}} 3: std::sys_common::backtrace::__rust_end_short_backtrace 4: std::panicking::begin_panic 5: tokio::runtime::blocking::shutdown::Receiver::wait 6: tokio::runtime::blocking::pool::BlockingPool::shutdown 7: core::ptr::drop_in_place<tokio::runtime::blocking::pool::BlockingPool> 8: core::ptr::drop_in_place<vaultwarden::schedule_jobs::{{closure}}::{{closure}}> 9: core::ptr::drop_in_place<std::thread::Builder::spawn_unchecked_<vaultwarden::schedule_jobs::{{closure}}::{{closure}},()>::{{closure}}> 10: std::sys::unix::thread::Thread::new 11: std::thread::Builder::spawn 12: vaultwarden::main::{{closure}} 13: tokio::park::thread::CachedParkThread::block_on 14: tokio::runtime::thread_pool::ThreadPool::block_on 15: rocket::async_main 16: vaultwarden::main 17: std::sys_common::backtrace::__rust_begin_short_backtrace 18: std::rt::lang_start::{{closure}} 19: std::rt::lang_start_internal 20: main 21: __libc_start_main 22: _start ``` ### Suggestion Limit maximum threads for pool to something like 16 or 32 (instead of the default `$(nproc)`) would be a good choice :) I don't think our nice program would have such huge load that requires a bunch of threads to handle

GiteaMirror closed this issue

2026-03-07 20:07:26 -06:00

GiteaMirror referenced this issue

2026-03-07 21:12:19 -06:00

[PR #4937] [MERGED] Fix collection update from native client #7175

GiteaMirror referenced this issue

2026-04-16 12:26:51 -05:00

[PR #4937] [MERGED] Fix collection update from native client #8475

GiteaMirror referenced this issue

2026-04-20 15:43:23 -05:00

[PR #4937] [MERGED] Fix collection update from native client #12401

GiteaMirror referenced this issue