mirror of
https://github.com/dani-garcia/vaultwarden.git
synced 2026-04-26 01:35:54 +03:00
[GH-ISSUE #759] 'main' panicking at running migrations #519
Labels
No 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
question
troubleshooting
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/vaultwarden#519
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @flexwie on GitHub (Dec 4, 2019).
Original GitHub issue: https://github.com/dani-garcia/vaultwarden/issues/759
Subject of the issue
When runnning the binaries, thread is pannicking at "Running migration 20180114171611"; throwing a formatter error.
Your environment
Steps to reproduce
build and start latest binaries
Relevant logs
Running migration 20180114171611
thread 'main' panicked at 'Can't run migrations: MigrationError(IoError(Custom { kind: Other, error: "formatter error" }))', src/libcore/result.rs:1187:5
stack backtrace:
0: backtrace::backtrace::libunwind::trace
at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.40/src/backtrace/libunwind.rs:88
1: backtrace::backtrace::trace_unsynchronized
at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.40/src/backtrace/mod.rs:66
2: std::sys_common::backtrace::_print_fmt
at src/libstd/sys_common/backtrace.rs:84
3: <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt
at src/libstd/sys_common/backtrace.rs:61
4: core::fmt::write
at src/libcore/fmt/mod.rs:1030
5: std::io::Write::write_fmt
at src/libstd/io/mod.rs:1412
6: std::sys_common::backtrace::_print
at src/libstd/sys_common/backtrace.rs:65
7: std::sys_common::backtrace::print
at src/libstd/sys_common/backtrace.rs:50
8: std::panicking::default_hook::{{closure}}
at src/libstd/panicking.rs:188
9: std::panicking::default_hook
at src/libstd/panicking.rs:205
10: std::panicking::rust_panic_with_hook
at src/libstd/panicking.rs:464
11: std::panicking::continue_panic_fmt
at src/libstd/panicking.rs:373
12: rust_begin_unwind
at src/libstd/panicking.rs:302
13: core::panicking::panic_fmt
at src/libcore/panicking.rs:82
14: core::result::unwrap_failed
at src/libcore/result.rs:1187
15: bitwarden_rs::migrations::run_migrations
16: bitwarden_rs::main
17: std::rt::lang_start::{{closure}}
18: std::rt::lang_start_internal::{{closure}}
at src/libstd/rt.rs:48
19: std::panicking::try::do_call
at src/libstd/panicking.rs:287
20: __rust_maybe_catch_panic
at src/libpanic_unwind/lib.rs:86
21: std::panicking::try
at src/libstd/panicking.rs:265
22: std::panic::catch_unwind
at src/libstd/panic.rs:395
23: std::rt::lang_start_internal
at src/libstd/rt.rs:47
24: main
25: __libc_start_main
26: _start
@mqus commented on GitHub (Dec 4, 2019):
What were the exact commands you used to build and execute bitwarden_rs? I just tried to build it and then run it using the following commands and it worked without an error.
(I didn't bother to build and include the vault so I disabled it for the experiment)
Which OS are you running on? I used Archlinux latest.
@mqus commented on GitHub (Dec 5, 2019):
Also, as this occurs in the database backend, could you mention which database you chose and the PostgreSql or MySql server version?
A first shot at a fix: You could try to remove the database and let bitwarden_rs add it from scratch, maybe it screwed up in a previous run.
@BlackDex commented on GitHub (Dec 5, 2019):
This could also be an issue with the connection to the database backend.
If it doesn't connect, or username/password is incorrect it will fail like this.
@flexwie commented on GitHub (Dec 6, 2019):
I deleted bitwardens database and rerun it without success... I can guarantee that the user and password combination is correct!
I am using MariaDB 10.038 on Ubuntu 16.04
@BlackDex commented on GitHub (Dec 6, 2019):
Hmm, i vaguely remember something like this with maria not working and mysql it did. I would have to try it my self again to be sure.
@pete1450 commented on GitHub (Dec 13, 2019):
I'm seeing the same thing on a fresh self built install with MariaDB 10.3.15. The initial start works fine and creates the tables but if I immediately stop the server and bring it back up I get the error. If I wipe the tables it's all good again but restart gets the error.
Update: If I rebuild it without the migrations it's fine. Temporary solution at least. From what I read I don't understand why they were trying to run at all though.
@BlackDex commented on GitHub (Dec 13, 2019):
@pete1450: Well those migrations will run always if the database is empty or if the migration timestamp is different between what is stored in the database and what the bitwarden_rs binary has built-in.
I Just tested it with
mysql Ver 14.14 Distrib 5.7.28, for Linux (x86_64) using EditLine wrapperAnd i can stop/start/stop/start a self-compiled bitwarden_rs server.
I have to try with MariaDB foo see if that will cause an issue for me, but this seems to just work fine.
@BlackDex commented on GitHub (Dec 13, 2019):
And i just have tested it with
mysql Ver 15.1 Distrib 10.3.21-MariaDB, for debian-linux-gnu (x86_64) using readline 5.2, which also gives no issues at all for me.Does the mysql user have all the right permissions?
@BlackDex commented on GitHub (Dec 13, 2019):
I even just build bitwarden_rs with only the mariadb libraries installed and it will use the libmariadb.so instead of libmysqlclient.so and also that works fine without issues.
Could you try the mysql docker build to rule out issues with building?
@flexwie commented on GitHub (Dec 31, 2019):
Sorry for coming back at you so late. I just created a new user with
grant all on bitwarden.* to 'user'@'%' identified by 'password';on a newly created database and still get the same error.I'm running
Ver 15.1 Distrib 10.1.43-MariaDB, for debian-linux-gnu (x86_64) using readline 5.2as a quite fresh installation.I will try the docker build tomorrow and report back.
@xe5700 commented on GitHub (Mar 11, 2020):
I have same issue with mariadb Ver 15.1 Distrib 10.5.1-MariaDB, for debian-linux-gnu (x86_64) using readline 5.2.
@nemchik commented on GitHub (Mar 18, 2020):
I'm using
bitwardenrs/server-mysqlwithlinuxserver/mariadband I have this issue with bw version 1.14, but reverting back to the 1.13.1 image seems to get it working again.@nemchik commented on GitHub (Mar 18, 2020):
Here's the log from my 1.14 container (where I saw the error)
@BlackDex commented on GitHub (Mar 18, 2020):
Well, this is related to using the beta version of MariaDB 10.5. Using MariaDB 10.4 has no issues.
Since 10.5 is beta i suggest to revert it back to the latest stable when possible.
@BlackDex commented on GitHub (Mar 18, 2020):
I created a fix for this so that during the migrations (creating and updating the base of the database) the Foreign Key Check is disabled. Which seems to be enabled by default in MariaDB 10.5.
@nemchik commented on GitHub (Mar 18, 2020):
It doesn't seem like I'm using mariadb 10.5
@BlackDex commented on GitHub (Mar 18, 2020):
Maybe the same check is enabled in your configuration or mariadb version by default. In anyway it should be fixed in the next build.
@nemchik commented on GitHub (Mar 18, 2020):
Awesome, thanks! I'll test the next build once I see it up!
@nemchik commented on GitHub (Apr 17, 2020):
I was able to get upgraded today. I tried
Version 1.14.2-5a390a97and saw the following indocker logs bitwardenI investigated using phpmyadmin and found there was a
org_policiestable in my database but it was empty (no rows). I made a backup of the database (used phpmyadmin's export option) and then dropped the table and restarted the container and everything seems to be working now.Anyone else having this issue might also have success trying
1.14.2or newer but may also need to drop theorg_policiestable (be sure to make backups!).@Gurkengewuerz commented on GitHub (May 13, 2020):
I am running the newest bitwarden release with sqlite support and it works like a charm, but if i migrate to mysql i get the exact error like @pete1450.
I built the newest version and ran bitwarden_rs once to create the schema. The table
__diesel_schema_migrationscreated and also has the right content but if i rerun bitwarden_rs, diesel wants to create the schema again.I am running bitwarden_rs in an lxc container on Debian 9 and
mysql Ver 15.1 Distrib 10.4.12-MariaDB, for Linux (x86_64) using readline 5.1on alpine 3.11 also in an lxc container.My first thought was that the time on both server were incorrect but this isnt the case.
@Gurkengewuerz commented on GitHub (May 13, 2020):
If I compile bitwarden_rs without migrations the server will start of course. Nevertheless I have a very strange behaviour. For instance I can't log in. Does it have something to do with WAL? In SQLite it was enabled (to my knowledge) and now it was disabled.
@jivanpal commented on GitHub (May 29, 2020):
I have a seemingly similar issue on Ubuntu 18.04 with MariaDB 10.1.44 (version from the Ubuntu repos).
Running Docker image
bitwardenrs/server-mysqlviadocker-composewithnetwork_mode: "host"to allow connection to a local MariaDB server. After first run, a table called__diesel_schema_migrationsis present, but it contains no data. This is a fresh instance of Bitwarden with no pre-existing/datafolder. The databasebitwardenis using character setutf8mb4and collationutf8mb4_unicode_ci.docker-compose.ymlMariaDB privileges
Output from
bitwardencontainer on first run usingdocker-compose up@jivanpal commented on GitHub (May 30, 2020):
Apologies, my issue is unrelated and now resolved. For those who may stumble across my comment in future:
The issue I'm encountering is due to the field
bitwarden.users.emailbeingVARCHAR(255) UNIQUE, thus being a key of maximum length 255 characters, plus a terminating null byte, which in conjunction with the character set beingutf8mb4, results in a maximum field size of 1021 bytes. This exceeds the default prefix length in MariaDB 10.1 InnoDB tables of 767 bytes.To resolve this, you can either use a smaller character set like
utf8(which, at max. 3 bytes per char, results in max. field length 766 bytes; thoughutf8is highly unrecommended), or enable large prefixes (which also requires using dynamic rows, switching the InnoDB file format from Antelope to Barracuda, and using one file per InnoDB table). See here for required settings.I believe no such change is needed for MariaDB 10.2 or later.
@BlackDex commented on GitHub (Oct 3, 2020):
There have been several database handling changes done since this report. Most of the regarding mysql/mariadb and foreign keys. Closing this one. Please open a new one when needed.