[GH-ISSUE #2593] Problems by updating form version 1.24.0 to version 1.25.0 #18089

New Issue

GiteaMirror · 2026-04-25T20:18:00-05:00

GiteaMirror commented

2026-04-25 20:18:00 -05:00

Originally created by @vsey on GitHub (Jul 4, 2022).
Original GitHub issue: https://github.com/dani-garcia/vaultwarden/issues/2593

Subject of the issue

When I update my vaultwarden instance from version 1.24.0 to version 1.25.0 the container dosen't start anymore and I get the following error in the podman logs:

/--------------------------------------------------------------------\
|                        Starting Vaultwarden                        |
|                           Version 1.25.0                           |
|--------------------------------------------------------------------|
| This is an *unofficial* Bitwarden implementation, DO NOT use the   |
| official channels to report bugs/features, regardless of client.   |
| Send usage/configuration questions or feature requests to:         |
|   https://vaultwarden.discourse.group/                             |
| Report suspected bugs/issues in the software itself at:            |
|   https://github.com/dani-garcia/vaultwarden/issues/new            |
\--------------------------------------------------------------------/

[INFO] No .env file found.

[2022-07-04 20:43:52.484][parity_ws][INFO] Listening for new connections on 0.0.0.0:3012.
[2022-07-04 20:43:52.491][start][INFO] Rocket has launched from http://0.0.0.0:80
[2022-07-04 20:43:52.513][panic][ERROR] thread 'job-scheduler' panicked at 'called `Result::unwrap()` on an `Err` value: Error { kind: Expression("Invalid cron expression.") }': src/main.rs:400
   0: vaultwarden::init_logging::{{closure}}
   1: std::panicking::rust_panic_with_hook
   2: std::panicking::begin_panic_handler::{{closure}}
   3: std::sys_common::backtrace::__rust_end_short_backtrace
   4: rust_begin_unwind
   5: core::panicking::panic_fmt
   6: core::result::unwrap_failed
   7: std::sys_common::backtrace::__rust_begin_short_backtrace
   8: core::ops::function::FnOnce::call_once{{vtable.shim}}
   9: std::sys::unix::thread::Thread::new::thread_start
  10: start_thread
  11: clone

[2022-07-04 20:43:52.523][panic][ERROR] thread 'job-scheduler' panicked at 'there is no reactor running, must be called from the context of a Tokio 1.x runtime': /root/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.18.2/src/runtime/context.rs:21
   0: vaultwarden::init_logging::{{closure}}
   1: std::panicking::rust_panic_with_hook
   2: std::panicking::begin_panic_handler::{{closure}}
   3: std::sys_common::backtrace::__rust_end_short_backtrace
   4: rust_begin_unwind
   5: core::panicking::panic_fmt
   6: core::panicking::panic_display
   7: tokio::runtime::blocking::pool::spawn_blocking
   8: core::ptr::drop_in_place<vaultwarden::db::DbPool>
   9: std::sys_common::backtrace::__rust_begin_short_backtrace
  10: core::ops::function::FnOnce::call_once{{vtable.shim}}
  11: std::sys::unix::thread::Thread::new::thread_start
  12: start_thread
  13: clone

thread panicked while panicking. aborting.

Deployment environment

docker-compose with podman on an fedora server

vaultwarden version: 1.25.0

Install method: Docker Image with docker-compose and podman
Clients used:
Reverse proxy and version:
MySQL/MariaDB or PostgreSQL version:
PostgreSQL
Other relevant details:

Steps to reproduce

Expected behaviour

Actual behaviour

Troubleshooting data

Originally created by @vsey on GitHub (Jul 4, 2022). Original GitHub issue: https://github.com/dani-garcia/vaultwarden/issues/2593   ### Subject of the issue When I update my vaultwarden instance from version 1.24.0 to version 1.25.0 the container dosen't start anymore and I get the following error in the podman logs: ``` /--------------------------------------------------------------------\ | Starting Vaultwarden | | Version 1.25.0 | |--------------------------------------------------------------------| | This is an *unofficial* Bitwarden implementation, DO NOT use the | | official channels to report bugs/features, regardless of client. | | Send usage/configuration questions or feature requests to: | | https://vaultwarden.discourse.group/ | | Report suspected bugs/issues in the software itself at: | | https://github.com/dani-garcia/vaultwarden/issues/new | \--------------------------------------------------------------------/ [INFO] No .env file found. [2022-07-04 20:43:52.484][parity_ws][INFO] Listening for new connections on 0.0.0.0:3012. [2022-07-04 20:43:52.491][start][INFO] Rocket has launched from http://0.0.0.0:80 [2022-07-04 20:43:52.513][panic][ERROR] thread 'job-scheduler' panicked at 'called `Result::unwrap()` on an `Err` value: Error { kind: Expression("Invalid cron expression.") }': src/main.rs:400 0: vaultwarden::init_logging::{{closure}} 1: std::panicking::rust_panic_with_hook 2: std::panicking::begin_panic_handler::{{closure}} 3: std::sys_common::backtrace::__rust_end_short_backtrace 4: rust_begin_unwind 5: core::panicking::panic_fmt 6: core::result::unwrap_failed 7: std::sys_common::backtrace::__rust_begin_short_backtrace 8: core::ops::function::FnOnce::call_once{{vtable.shim}} 9: std::sys::unix::thread::Thread::new::thread_start 10: start_thread 11: clone [2022-07-04 20:43:52.523][panic][ERROR] thread 'job-scheduler' panicked at 'there is no reactor running, must be called from the context of a Tokio 1.x runtime': /root/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.18.2/src/runtime/context.rs:21 0: vaultwarden::init_logging::{{closure}} 1: std::panicking::rust_panic_with_hook 2: std::panicking::begin_panic_handler::{{closure}} 3: std::sys_common::backtrace::__rust_end_short_backtrace 4: rust_begin_unwind 5: core::panicking::panic_fmt 6: core::panicking::panic_display 7: tokio::runtime::blocking::pool::spawn_blocking 8: core::ptr::drop_in_place<vaultwarden::db::DbPool> 9: std::sys_common::backtrace::__rust_begin_short_backtrace 10: core::ops::function::FnOnce::call_once{{vtable.shim}} 11: std::sys::unix::thread::Thread::new::thread_start 12: start_thread 13: clone thread panicked while panicking. aborting. ``` ### Deployment environment docker-compose with podman on an fedora server     * vaultwarden version: 1.25.0  * Install method: Docker Image with docker-compose and podman * Clients used:  * Reverse proxy and version:  * MySQL/MariaDB or PostgreSQL version:  PostgreSQL * Other relevant details: ### Steps to reproduce  ### Expected behaviour  ### Actual behaviour  ### Troubleshooting data

GiteaMirror closed this issue

2026-04-25 20:18:00 -05:00

GiteaMirror commented

2026-04-25 20:18:01 -05:00

@vsey commented on GitHub (Jul 4, 2022):

I found the problem, the problem is in the environment variables, because this

      # Cron schedule of the job that checks for trashed items to delete permanently.
      # Defaults to daily (5 minutes after midnight). Set blank to disable this job.
      - TRASH_PURGE_SCHEDULE=""

works in version 1.24.0 but not in version 1.25.0, by out commenting the TRASH_PURGE_SCHEDULE="" the container starts now and works

@vsey commented on GitHub (Jul 4, 2022): I found the problem, the problem is in the environment variables, because this ``` # Cron schedule of the job that checks for trashed items to delete permanently. # Defaults to daily (5 minutes after midnight). Set blank to disable this job. - TRASH_PURGE_SCHEDULE="" ``` works in version 1.24.0 but not in version 1.25.0, by out commenting the TRASH_PURGE_SCHEDULE="" the container starts now and works

GiteaMirror commented

2026-04-25 20:18:02 -05:00

@BlackDex commented on GitHub (Jul 4, 2022):

You need to remove the quote's just the = is enough to have it empty.

@BlackDex commented on GitHub (Jul 4, 2022): You need to remove the quote's just the = is enough to have it empty.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/vaultwarden#18089