Originally created by @pew on GitHub (Nov 21, 2018).
Hi,
I'm using the current bitwarden_rs mprasil/bitwarden:1.4.0-alpine docker image with WEBSOCKET_ENABLED=true configured (and caddy as my proxy, also with websockets enabled), I also have a healthcheck configured for port 80 and 3012 within the container.
After one to two minutes the healthcheck for 3012 is failing. Container log:
thread '<unnamed>' panicked at 'called `Option::unwrap()` on a `None` value', libcore/option.rs:345:21
with the backtrace enabled:
stack backtrace:
0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
at libstd/sys/unix/backtrace/tracing/gcc_s.rs:49
1: std::sys_common::backtrace::print
at libstd/sys_common/backtrace.rs:71
at libstd/sys_common/backtrace.rs:59
2: std::panicking::default_hook::{{closure}}
at libstd/panicking.rs:211
3: std::panicking::default_hook
at libstd/panicking.rs:227
4: std::panicking::rust_panic_with_hook
at libstd/panicking.rs:476
5: std::panicking::continue_panic_fmt
at libstd/panicking.rs:390
6: rust_begin_unwind
at libstd/panicking.rs:325
7: core::panicking::panic_fmt
at libcore/panicking.rs:77
8: core::panicking::panic
at libcore/panicking.rs:52
9: <bitwarden_rs::api::notifications::WSFactory as ws::factory::Factory>::connection_lost
10: <ws::io::Handler<F>>::check_active
11: <ws::io::Handler<F>>::run
12: <ws::WebSocket<F>>::listen
Originally created by @pew on GitHub (Nov 21, 2018).
Hi,
I'm using the current bitwarden_rs `mprasil/bitwarden:1.4.0-alpine` docker image with `WEBSOCKET_ENABLED=true` configured (and caddy as my proxy, also with websockets enabled), I also have a healthcheck configured for port 80 and 3012 within the container.
After one to two minutes the healthcheck for 3012 is failing. Container log:
```
thread '<unnamed>' panicked at 'called `Option::unwrap()` on a `None` value', libcore/option.rs:345:21
```
with the backtrace enabled:
```
stack backtrace:
0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
at libstd/sys/unix/backtrace/tracing/gcc_s.rs:49
1: std::sys_common::backtrace::print
at libstd/sys_common/backtrace.rs:71
at libstd/sys_common/backtrace.rs:59
2: std::panicking::default_hook::{{closure}}
at libstd/panicking.rs:211
3: std::panicking::default_hook
at libstd/panicking.rs:227
4: std::panicking::rust_panic_with_hook
at libstd/panicking.rs:476
5: std::panicking::continue_panic_fmt
at libstd/panicking.rs:390
6: rust_begin_unwind
at libstd/panicking.rs:325
7: core::panicking::panic_fmt
at libcore/panicking.rs:77
8: core::panicking::panic
at libcore/panicking.rs:52
9: <bitwarden_rs::api::notifications::WSFactory as ws::factory::Factory>::connection_lost
10: <ws::io::Handler<F>>::check_active
11: <ws::io::Handler<F>>::run
12: <ws::WebSocket<F>>::listen
```
Note that there's a fix in #263 to allow us building alpine image again. So if you want to test the fix now, you need to build manually (with the alpine fix applied) or wait until that gets merged.
@mprasil commented on GitHub (Nov 21, 2018):
Note that there's a fix in #263 to allow us building alpine image again. So if you want to test the fix now, you need to build manually (with the alpine fix applied) or wait until that gets merged.
The changes were now merged and the alpine image is now building. Give it about an hour and it should be available.
@mprasil commented on GitHub (Nov 21, 2018):
The changes were now merged and the [alpine image is now building](https://hub.docker.com/r/mprasil/bitwarden/builds/bjmed4lvre5agtan9dgfvea/). Give it about an hour and it should be available.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Originally created by @pew on GitHub (Nov 21, 2018).
Hi,
I'm using the current bitwarden_rs
mprasil/bitwarden:1.4.0-alpinedocker image withWEBSOCKET_ENABLED=trueconfigured (and caddy as my proxy, also with websockets enabled), I also have a healthcheck configured for port 80 and 3012 within the container.After one to two minutes the healthcheck for 3012 is failing. Container log:
with the backtrace enabled:
@dani-garcia commented on GitHub (Nov 21, 2018):
I removed the unwrap that was making the code panic. It should be fixed now in the latest master
@mprasil commented on GitHub (Nov 21, 2018):
Note that there's a fix in #263 to allow us building alpine image again. So if you want to test the fix now, you need to build manually (with the alpine fix applied) or wait until that gets merged.
@mprasil commented on GitHub (Nov 21, 2018):
The changes were now merged and the alpine image is now building. Give it about an hour and it should be available.