panic in testing docker image on Raspberry Pi 4 #1118

New Issue

Closed

opened 2026-02-04 23:57:21 +03:00 by OVERLORD · 5 comments

OVERLORD commented 2026-02-04 23:57:21 +03:00

Owner

Copy Link

Originally created by @krzmaz on GitHub (Sep 26, 2021).

Subject of the issue

When trying to run the testing docker image, there is a panic and the container stops:

~/vw-data $ docker run -i --name vaultwarden -p 8090:80 vaultwarden/server:testing
/--------------------------------------------------------------------\
|                        Starting Vaultwarden                        |
|                      Version 1.22.2-b4c95fb4                       |
|--------------------------------------------------------------------|
| 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.

thread panicked while processing panic. aborting.
~/vw-data $

Latest image that I've found to be working is

vaultwarden/server:testing@sha256:b1819c383ce7e086c115dc816ef5dc8ecb5e77ec647fee7dc052015c1e98b5e8

from https://github.com/dani-garcia/vaultwarden/runs/3549020743

The next run of Release workflow: https://github.com/dani-garcia/vaultwarden/runs/3549706175
produced the image

vaultwarden/server@sha256:49bda0a9f866a1a5cb7847332ddeabf03a0d9ca50d59ecc485a92ddbf88abdbc

that gives:

Digest: sha256:49bda0a9f866a1a5cb7847332ddeabf03a0d9ca50d59ecc485a92ddbf88abdbc
Status: Downloaded newer image for vaultwarden/server@sha256:49bda0a9f866a1a5cb7847332ddeabf03a0d9ca50d59ecc485a92ddbf88abdbc
/--------------------------------------------------------------------\
|                        Starting Vaultwarden                        |
|                      Version 1.22.2-d5ed2ce6                       |
|--------------------------------------------------------------------|
| 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.

thread panicked while processing panic. aborting.
DEBU[0059] [hijack] End of stdout

Deployment environment

• vaultwarden version:

• Install method: docker image

• Clients used:

• Reverse proxy and version:

• MySQL/MariaDB or PostgreSQL version:

• Other relevant details:
  More info on the hardware used:

$ cat /proc/cpuinfo
processor	: 0
model name	: ARMv7 Processor rev 3 (v7l)
BogoMIPS	: 108.00
Features	: half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm crc32
CPU implementer	: 0x41
CPU architecture: 7
CPU variant	: 0x0
CPU part	: 0xd08
CPU revision	: 3

processor	: 1
model name	: ARMv7 Processor rev 3 (v7l)
BogoMIPS	: 108.00
Features	: half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm crc32
CPU implementer	: 0x41
CPU architecture: 7
CPU variant	: 0x0
CPU part	: 0xd08
CPU revision	: 3

processor	: 2
model name	: ARMv7 Processor rev 3 (v7l)
BogoMIPS	: 108.00
Features	: half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm crc32
CPU implementer	: 0x41
CPU architecture: 7
CPU variant	: 0x0
CPU part	: 0xd08
CPU revision	: 3

processor	: 3
model name	: ARMv7 Processor rev 3 (v7l)
BogoMIPS	: 108.00
Features	: half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm crc32
CPU implementer	: 0x41
CPU architecture: 7
CPU variant	: 0x0
CPU part	: 0xd08
CPU revision	: 3

Hardware	: BCM2711
Revision	: c03112
Serial		: 1000000016faaf92
Model		: Raspberry Pi 4 Model B Rev 1.2

Steps to reproduce

docker --debug run --rm -it --name vaultwarden -e RUST_BACKTRACE=1 -e LOG_LEVEL=trace -p 8090:80 vaultwarden/server:testing

Expected behaviour

Running vaultwarden container

Actual behaviour

Container stops after panic

Troubleshooting data

Originally created by @krzmaz on GitHub (Sep 26, 2021). <!-- # ### NOTE: Please update to the latest version of vaultwarden before reporting an issue! This saves you and us a lot of time and troubleshooting. See: * https://github.com/dani-garcia/vaultwarden/issues/1180 * https://github.com/dani-garcia/vaultwarden/wiki/Updating-the-vaultwarden-image # ### --> <!-- Please fill out the following template to make solving your problem easier and faster for us. This is only a guideline. If you think that parts are unnecessary for your issue, feel free to remove them. Remember to hide/redact personal or confidential information, such as passwords, IP addresses, and DNS names as appropriate. --> ### Subject of the issue <!-- Describe your issue here. --> When trying to run the `testing` docker image, there is a panic and the container stops: ``` ~/vw-data $ docker run -i --name vaultwarden -p 8090:80 vaultwarden/server:testing /--------------------------------------------------------------------\ | Starting Vaultwarden | | Version 1.22.2-b4c95fb4 | |--------------------------------------------------------------------| | 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. thread panicked while processing panic. aborting. ~/vw-data $ ``` Latest image that I've found to be working is ``` vaultwarden/server:testing@sha256:b1819c383ce7e086c115dc816ef5dc8ecb5e77ec647fee7dc052015c1e98b5e8 ``` from https://github.com/dani-garcia/vaultwarden/runs/3549020743 The next run of `Release` workflow: https://github.com/dani-garcia/vaultwarden/runs/3549706175 produced the image ``` vaultwarden/server@sha256:49bda0a9f866a1a5cb7847332ddeabf03a0d9ca50d59ecc485a92ddbf88abdbc ``` that gives: ``` Digest: sha256:49bda0a9f866a1a5cb7847332ddeabf03a0d9ca50d59ecc485a92ddbf88abdbc Status: Downloaded newer image for vaultwarden/server@sha256:49bda0a9f866a1a5cb7847332ddeabf03a0d9ca50d59ecc485a92ddbf88abdbc /--------------------------------------------------------------------\ | Starting Vaultwarden | | Version 1.22.2-d5ed2ce6 | |--------------------------------------------------------------------| | 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. thread panicked while processing panic. aborting. DEBU[0059] [hijack] End of stdout ``` ### Deployment environment <!-- ========================================================================================= Preferably, use the `Generate Support String` button on the admin page's Diagnostics tab. That will auto-generate most of the info requested in this section. ========================================================================================= --> <!-- The version number, obtained from the logs (at startup) or the admin diagnostics page --> <!-- This is NOT the version number shown on the web vault, which is versioned separately from vaultwarden --> <!-- Remember to check if your issue exists on the latest version first! --> * vaultwarden version: <!-- How the server was installed: Docker image, OS package, built from source, etc. --> * Install method: docker image * Clients used: <!-- web vault, desktop, Android, iOS, etc. (if applicable) --> * Reverse proxy and version: <!-- if applicable --> * MySQL/MariaDB or PostgreSQL version: <!-- if applicable --> * Other relevant details: More info on the hardware used: ``` $ cat /proc/cpuinfo processor : 0 model name : ARMv7 Processor rev 3 (v7l) BogoMIPS : 108.00 Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm crc32 CPU implementer : 0x41 CPU architecture: 7 CPU variant : 0x0 CPU part : 0xd08 CPU revision : 3 processor : 1 model name : ARMv7 Processor rev 3 (v7l) BogoMIPS : 108.00 Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm crc32 CPU implementer : 0x41 CPU architecture: 7 CPU variant : 0x0 CPU part : 0xd08 CPU revision : 3 processor : 2 model name : ARMv7 Processor rev 3 (v7l) BogoMIPS : 108.00 Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm crc32 CPU implementer : 0x41 CPU architecture: 7 CPU variant : 0x0 CPU part : 0xd08 CPU revision : 3 processor : 3 model name : ARMv7 Processor rev 3 (v7l) BogoMIPS : 108.00 Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm crc32 CPU implementer : 0x41 CPU architecture: 7 CPU variant : 0x0 CPU part : 0xd08 CPU revision : 3 Hardware : BCM2711 Revision : c03112 Serial : 1000000016faaf92 Model : Raspberry Pi 4 Model B Rev 1.2 ``` ### Steps to reproduce <!-- Tell us how to reproduce this issue. What parameters did you set (differently from the defaults) and how did you start vaultwarden? --> ``` docker --debug run --rm -it --name vaultwarden -e RUST_BACKTRACE=1 -e LOG_LEVEL=trace -p 8090:80 vaultwarden/server:testing ``` ### Expected behaviour <!-- Tell us what you expected to happen --> Running vaultwarden container ### Actual behaviour <!-- Tell us what actually happened --> Container stops after panic ### Troubleshooting data <!-- Share any log files, screenshots, or other relevant troubleshooting data -->

OVERLORD added the bugThird party labels 2026-02-04 23:57:21 +03:00

OVERLORD closed this issue 2026-02-04 23:57:25 +03:00

OVERLORD commented 2026-02-04 23:57:32 +03:00

Author

Owner

Copy Link

@BlackDex commented on GitHub (Sep 26, 2021):

For me, on a RPi2b it does continue a bit further, but also fails:

[2021-09-26 17:38:46.565][panic][ERROR] thread 'job-scheduler' panicked at 'assertion failed: `(left == right)`
  left: `1`,
 right: `4`': library/std/src/sys/unix/thread.rs:217
   0: backtrace::backtrace::trace
   1: backtrace::capture::Backtrace::new
   2: vaultwarden::init_logging::{{closure}}
   3: std::panicking::rust_panic_with_hook
             at rustc/ac2d9fc509e36d1b32513744adf58c34bcc4f43c/library/std/src/panicking.rs:628:17
   4: std::panicking::begin_panic_handler::{{closure}}
             at rustc/ac2d9fc509e36d1b32513744adf58c34bcc4f43c/library/std/src/panicking.rs:521:13
   5: std::sys_common::backtrace::__rust_end_short_backtrace
             at rustc/ac2d9fc509e36d1b32513744adf58c34bcc4f43c/library/std/src/sys_common/backtrace.rs:141:18
   6: rust_begin_unwind
             at rustc/ac2d9fc509e36d1b32513744adf58c34bcc4f43c/library/std/src/panicking.rs:517:5
   7: core::panicking::panic_fmt
             at rustc/ac2d9fc509e36d1b32513744adf58c34bcc4f43c/library/core/src/panicking.rs:103:14
   8: core::panicking::assert_failed_inner
   9: core::panicking::assert_failed
             at rustc/ac2d9fc509e36d1b32513744adf58c34bcc4f43c/library/core/src/panicking.rs:141:5
  10: std::sys::unix::thread::Thread::sleep
             at rustc/ac2d9fc509e36d1b32513744adf58c34bcc4f43c/library/std/src/sys/unix/thread.rs:217:21
      std::thread::sleep
             at rustc/ac2d9fc509e36d1b32513744adf58c34bcc4f43c/library/std/src/thread/mod.rs:810:5
  11: vaultwarden::schedule_jobs::{{closure}}
  12: std::sys_common::backtrace::__rust_begin_short_backtrace
  13: core::ops::function::FnOnce::call_once{{vtable.shim}}
  14: <alloc::boxed::Box<F,A> as core::ops::function::FnOnce<Args>>::call_once
             at rustc/ac2d9fc509e36d1b32513744adf58c34bcc4f43c/library/alloc/src/boxed.rs:1636:9
      <alloc::boxed::Box<F,A> as core::ops::function::FnOnce<Args>>::call_once
             at rustc/ac2d9fc509e36d1b32513744adf58c34bcc4f43c/library/alloc/src/boxed.rs:1636:9
      std::sys::unix::thread::Thread::new::thread_start
             at rustc/ac2d9fc509e36d1b32513744adf58c34bcc4f43c/library/std/src/sys/unix/thread.rs:106:17

@BlackDex commented on GitHub (Sep 26, 2021): For me, on a RPi2b it does continue a bit further, but also fails: ``` [2021-09-26 17:38:46.565][panic][ERROR] thread 'job-scheduler' panicked at 'assertion failed: `(left == right)` left: `1`, right: `4`': library/std/src/sys/unix/thread.rs:217 0: backtrace::backtrace::trace 1: backtrace::capture::Backtrace::new 2: vaultwarden::init_logging::{{closure}} 3: std::panicking::rust_panic_with_hook at rustc/ac2d9fc509e36d1b32513744adf58c34bcc4f43c/library/std/src/panicking.rs:628:17 4: std::panicking::begin_panic_handler::{{closure}} at rustc/ac2d9fc509e36d1b32513744adf58c34bcc4f43c/library/std/src/panicking.rs:521:13 5: std::sys_common::backtrace::__rust_end_short_backtrace at rustc/ac2d9fc509e36d1b32513744adf58c34bcc4f43c/library/std/src/sys_common/backtrace.rs:141:18 6: rust_begin_unwind at rustc/ac2d9fc509e36d1b32513744adf58c34bcc4f43c/library/std/src/panicking.rs:517:5 7: core::panicking::panic_fmt at rustc/ac2d9fc509e36d1b32513744adf58c34bcc4f43c/library/core/src/panicking.rs:103:14 8: core::panicking::assert_failed_inner 9: core::panicking::assert_failed at rustc/ac2d9fc509e36d1b32513744adf58c34bcc4f43c/library/core/src/panicking.rs:141:5 10: std::sys::unix::thread::Thread::sleep at rustc/ac2d9fc509e36d1b32513744adf58c34bcc4f43c/library/std/src/sys/unix/thread.rs:217:21 std::thread::sleep at rustc/ac2d9fc509e36d1b32513744adf58c34bcc4f43c/library/std/src/thread/mod.rs:810:5 11: vaultwarden::schedule_jobs::{{closure}} 12: std::sys_common::backtrace::__rust_begin_short_backtrace 13: core::ops::function::FnOnce::call_once{{vtable.shim}} 14: <alloc::boxed::Box<F,A> as core::ops::function::FnOnce<Args>>::call_once at rustc/ac2d9fc509e36d1b32513744adf58c34bcc4f43c/library/alloc/src/boxed.rs:1636:9 <alloc::boxed::Box<F,A> as core::ops::function::FnOnce<Args>>::call_once at rustc/ac2d9fc509e36d1b32513744adf58c34bcc4f43c/library/alloc/src/boxed.rs:1636:9 std::sys::unix::thread::Thread::new::thread_start at rustc/ac2d9fc509e36d1b32513744adf58c34bcc4f43c/library/std/src/sys/unix/thread.rs:106:17 ```

OVERLORD commented 2026-02-04 23:57:38 +03:00

Author

Owner

Copy Link

@BlackDex commented on GitHub (Sep 26, 2021):

I'm currently testing if it is the bullseye vs buster or the building-process

@BlackDex commented on GitHub (Sep 26, 2021): I'm currently testing if it is the bullseye vs buster or the building-process

OVERLORD commented 2026-02-04 23:57:41 +03:00

Author

Owner

Copy Link

@BlackDex commented on GitHub (Sep 26, 2021):

Seems to be an issue with the bullseye images.
It doesn't matter if i build with buster and run on bullseye it still breaks.

Building with bullseye and running on buster isn't possible because of updated glibc versions.
So, i think we need to revert back to buster for the time being, since if i just buster for both building and the final image, it works just fine.

@BlackDex commented on GitHub (Sep 26, 2021): Seems to be an issue with the bullseye images. It doesn't matter if i build with buster and run on bullseye it still breaks. Building with bullseye and running on buster isn't possible because of updated glibc versions. So, i think we need to revert back to buster for the time being, since if i just buster for both building and the final image, it works just fine.

OVERLORD commented 2026-02-04 23:57:45 +03:00

Author

Owner

Copy Link

@dani-garcia commented on GitHub (Sep 27, 2021):

The error is originated here:
c09d637432/library/std/src/sys/unix/thread.rs (L217)

libc::EINTR has the value 4 mentioned in the assert panic, so it seems like the libc nanosleep is failing on bullseye. We should return to buster for both images for now.

@dani-garcia commented on GitHub (Sep 27, 2021): The error is originated here: https://github.com/rust-lang/rust/blob/c09d6374324ee23cb5a4fe738f74369717dd642d/library/std/src/sys/unix/thread.rs#L217 [libc::EINTR](https://docs.rs/libc/0.2.102/libc/constant.EINTR.html) has the value 4 mentioned in the assert panic, so it seems like the libc nanosleep is failing on bullseye. We should return to buster for both images for now.

OVERLORD commented 2026-02-04 23:57:54 +03:00

Author

Owner

Copy Link

@BlackDex commented on GitHub (Sep 27, 2021):

A quick search on this EINTR 4 (Sigill) status and bullseye seems to be bugging more dockerized software like MongoDB and Gitlab.

@BlackDex commented on GitHub (Sep 27, 2021): A quick search on this EINTR 4 (Sigill) status and bullseye seems to be bugging more dockerized software like MongoDB and Gitlab.

Sign in to join this conversation.

No Branch/Tag Specified

Branches Tags

main

cached-config-operations

test_dylint

1.35.2

1.35.1

1.35.0

1.34.3

1.34.2

1.34.1

1.34.0

1.33.2

1.33.1

1.33.0

1.32.7

1.32.6

1.32.5

1.32.4

1.32.3

1.32.2

1.32.1

1.32.0

1.31.0

1.30.5

1.30.4

1.30.3

1.30.2

1.30.1

1.30.0

1.29.2

1.29.1

1.29.0

1.28.1

1.28.0

1.27.0

1.26.0

1.25.2

1.25.1

1.25.0

1.24.0

1.23.1

1.23.0

1.22.2

1.22.1

1.22.0

1.21.0

1.20.0

1.19.0

1.18.0

1.17.0

1.16.3

1.16.2

1.16.1

1.16.0

1.15.1

1.15.0

1.14.2

1.14.1

1.14

1.13.1

1.13.0

1.12.0

1.11.0

1.10.0

1.9.1

1.9.0

1.8.0

1.7.0

1.6.1

1.6.0

1.5.0

1.4.0

1.3.0

1.2.0

1.1.0

1.0.0

0.13.0

0.12.0

0.11.0

0.10.0

0.9.0

Labels

Clear labels

SSO

Third party

better for forum

bug

bug

documentation

duplicate

enhancement

future Vault

future Vault

future Vault

good first issue

help wanted

low priority

notes

pull-request

Mirrored from GitHub Pull Request

question

troubleshooting

wontfix

No Label Third party bug

Milestone

No items

No Milestone

Projects

Clear projects

No project

Assignees

Clear assignees

OVERLORD

No Assignees

1 Participants

Notifications

Subscribe

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/vaultwarden#1118