[GH-ISSUE #2283] Diagnostics page "admin/diagnostics" in webvault not displayed if resolv.conf contains invalid values #1210

New issue

Closed

opened 2026-03-03 02:07:10 +03:00 by kerem · 2 comments

kerem commented

2026-03-03 02:07:10 +03:00

Owner

Originally created by @IchSchreiGleich on GitHub (Feb 1, 2022).
Original GitHub issue: https://github.com/dani-garcia/vaultwarden/issues/2283

Subject of the issue

The diagnostic page of an admin login is not displayed if an invalid option is included in resolv.conf

Deployment environment

vaultwarden version: 1.24.0-08f0de7b (webvault 2.25.1b)
Install method: built from source
Clients used: webbrowser

Steps to reproduce

Add a invalid line to resolve.conf like "option xxx_yyy"

Expected behaviour

Instead of not displaying the diagnostic page at all, only the corresponding part of the page should be marked as "not evaluable".

Actual behaviour

Diagnostic page is not displayed

Troubleshooting data

[2022-02-01 09:49:27.400][request][INFO] GET /admin/diagnostics
[2022-02-01 09:49:27.400][panic][ERROR] thread 'unnamed' panicked at 'Failed to build client: reqwest::Error { kind: Builder, source: Custom { kind: Other, error: "error reading DNS system conf: Error parsing resolv.conf: InvalidOption(4)" } }': src/util.rs:623
   0: vaultwarden::init_logging::{{closure}}
   1: std::panicking::rust_panic_with_hook
             at /rustc/498eeb72f590e518e19746b346be53713689e207/library/std/src/panicking.rs:695:17
   2: std::panicking::begin_panic_handler::{{closure}}
             at /rustc/498eeb72f590e518e19746b346be53713689e207/library/std/src/panicking.rs:581:13
   3: std::sys_common::backtrace::__rust_end_short_backtrace
             at /rustc/498eeb72f590e518e19746b346be53713689e207/library/std/src/sys_common/backtrace.rs:139:18
   4: rust_begin_unwind
             at /rustc/498eeb72f590e518e19746b346be53713689e207/library/std/src/panicking.rs:577:5
   5: core::panicking::panic_fmt
             at /rustc/498eeb72f590e518e19746b346be53713689e207/library/core/src/panicking.rs:135:14
   6: core::result::unwrap_failed
             at /rustc/498eeb72f590e518e19746b346be53713689e207/library/core/src/result.rs:1737:5
   7: vaultwarden::api::admin::diagnostics
   8: vaultwarden::api::admin::rocket_route_fn_diagnostics
   9: <F as rocket::handler::Handler>::handle
  10: rocket::rocket::Rocket::route_and_process
  11: <rocket::rocket::Rocket as hyper::server::Handler>::handle
  12: hyper::server::Worker<H>::handle_connection
  13: std::sys_common::backtrace::__rust_begin_short_backtrace
  14: core::ops::function::FnOnce::call_once{{vtable.shim}}
  15: <alloc::boxed::Box<F,A> as core::ops::function::FnOnce<Args>>::call_once
             at /rustc/498eeb72f590e518e19746b346be53713689e207/library/alloc/src/boxed.rs:1854:9
      <alloc::boxed::Box<F,A> as core::ops::function::FnOnce<Args>>::call_once
             at /rustc/498eeb72f590e518e19746b346be53713689e207/library/alloc/src/boxed.rs:1854:9
      std::sys::unix::thread::Thread::new::thread_start
             at /rustc/498eeb72f590e518e19746b346be53713689e207/library/std/src/sys/unix/thread.rs:108:17
  16: <unknown>

https://github.com/dani-garcia/bw_web_builds/issues/60#issuecomment-1026618578

Originally created by @IchSchreiGleich on GitHub (Feb 1, 2022). Original GitHub issue: https://github.com/dani-garcia/vaultwarden/issues/2283 ### Subject of the issue The diagnostic page of an admin login is not displayed if an invalid option is included in resolv.conf ### Deployment environment * vaultwarden version: 1.24.0-08f0de7b (webvault 2.25.1b) * Install method: built from source * Clients used: webbrowser ### Steps to reproduce Add a invalid line to resolve.conf like "option xxx_yyy" ### Expected behaviour Instead of not displaying the diagnostic page at all, only the corresponding part of the page should be marked as "not evaluable". ### Actual behaviour Diagnostic page is not displayed ### Troubleshooting data ``` [2022-02-01 09:49:27.400][request][INFO] GET /admin/diagnostics [2022-02-01 09:49:27.400][panic][ERROR] thread 'unnamed' panicked at 'Failed to build client: reqwest::Error { kind: Builder, source: Custom { kind: Other, error: "error reading DNS system conf: Error parsing resolv.conf: InvalidOption(4)" } }': src/util.rs:623 0: vaultwarden::init_logging::{{closure}} 1: std::panicking::rust_panic_with_hook at /rustc/498eeb72f590e518e19746b346be53713689e207/library/std/src/panicking.rs:695:17 2: std::panicking::begin_panic_handler::{{closure}} at /rustc/498eeb72f590e518e19746b346be53713689e207/library/std/src/panicking.rs:581:13 3: std::sys_common::backtrace::__rust_end_short_backtrace at /rustc/498eeb72f590e518e19746b346be53713689e207/library/std/src/sys_common/backtrace.rs:139:18 4: rust_begin_unwind at /rustc/498eeb72f590e518e19746b346be53713689e207/library/std/src/panicking.rs:577:5 5: core::panicking::panic_fmt at /rustc/498eeb72f590e518e19746b346be53713689e207/library/core/src/panicking.rs:135:14 6: core::result::unwrap_failed at /rustc/498eeb72f590e518e19746b346be53713689e207/library/core/src/result.rs:1737:5 7: vaultwarden::api::admin::diagnostics 8: vaultwarden::api::admin::rocket_route_fn_diagnostics 9: <F as rocket::handler::Handler>::handle 10: rocket::rocket::Rocket::route_and_process 11: <rocket::rocket::Rocket as hyper::server::Handler>::handle 12: hyper::server::Worker<H>::handle_connection 13: std::sys_common::backtrace::__rust_begin_short_backtrace 14: core::ops::function::FnOnce::call_once{{vtable.shim}} 15: <alloc::boxed::Box<F,A> as core::ops::function::FnOnce<Args>>::call_once at /rustc/498eeb72f590e518e19746b346be53713689e207/library/alloc/src/boxed.rs:1854:9 <alloc::boxed::Box<F,A> as core::ops::function::FnOnce<Args>>::call_once at /rustc/498eeb72f590e518e19746b346be53713689e207/library/alloc/src/boxed.rs:1854:9 std::sys::unix::thread::Thread::new::thread_start at /rustc/498eeb72f590e518e19746b346be53713689e207/library/std/src/sys/unix/thread.rs:108:17 16: <unknown> ``` https://github.com/dani-garcia/bw_web_builds/issues/60#issuecomment-1026618578

kerem

2026-03-03 02:07:10 +03:00

closed this issue
added the
bug

low priority
labels

kerem commented

2026-03-03 02:07:11 +03:00

Author

Owner

@BlackDex commented on GitHub (Feb 1, 2022):

Confirmed

@BlackDex commented on GitHub (Feb 1, 2022): Confirmed

kerem commented

2026-03-03 02:07:11 +03:00

Author

Owner

@BlackDex commented on GitHub (Feb 22, 2022):

Small update, i have a working fix for this in the async branch locally on my system. I that should solve the panic at least.

@BlackDex commented on GitHub (Feb 22, 2022): Small update, i have a working fix for this in the async branch locally on my system. I that should solve the panic at least.