Client does not detect corrupt mumble.sqlite db #3254
Comments
davidebeatrici
added
feature-request
In a userbase of primarily gamers system instabilities aren't that uncommon. Without synchronisation of the user-db this can lead to corruption of our client database storing the user-certificate. We have had various reports of such issues over time. The current mode was set in 2010 in commit 9fee66e to speed up the client-db "even more" though it is unclear whether we actually had performance problems that required this step. This patch switches the client synchronisation mode from OFF to NORMAL which according to the sqlite documentation will leave a "very small" chance for database corruption but is than the default FULL sync mode. This commit should partially address issue mumble-voip#3254 by making database corruption much more unlikely but detecting corruption and/or handling DB backups are further possible approaches if this change turns out to have unacceptable performance or we get further reports of durability issues with the clientside DB.
In a userbase of primarily gamers system instabilities aren't that uncommon. Without synchronization of the user-db this can lead to corruption of our client database storing the user-certificate. We have had various reports of such issues over time. The current mode was set in 2010 in commit 9fee66e to speed up the client-db "even more" though it is unclear whether we actually had performance problems that required this step. This patch switches the client synchronization mode from OFF to NORMAL which according to the sqlite documentation will leave a "very small" chance for database corruption but is than the default FULL sync mode. This commit should partially address issue mumble-voip#3254 by making database corruption much more unlikely but detecting corruption and/or handling DB backups are further possible approaches if this change turns out to have unacceptable performance or we get further reports of durability issues with the clientside DB.
|
The changes landed in #3255 should make client DB corruption much less likely. Still leaving this open as detecting issues and regular client DB backups could be additional features. |
|
A)Is there a way I can get the updated client and I will test some very brutal conditions. Found what I need, please ignore A) B)Does this mean that the process now will be something like a db write and immediate flush so there won't be contents in a buffer somewhere? Great fast response. |
|
@Grandpa-G I triggered a 1.3 snapshot which should become available through download/auto-update in the next few hours. Name should contain 53c5a91 . Definitely interested in your feedback. W.r.t to your other point. Yes. The DB should now force the OS to flush the DB changes do disk regularly enough to make database corruption due to system crashes very unlikely. Previously the DB handed the data over to the OS but didn't force it to write it immediatly. That means Mumble crashing wasn't a problem, but if the whole system went down (e.g. due to a bluescreen or power outage) while critical data was still buffered by the OS the database could get corrupted. |
When the client starts, there a number of checks for db file accessibility. However there are no checks for a corrupted db. Thus, when any type of sql statements are executed, they fail and just logged. The main way to notice this is that the server certificate cannot be saved and thus an infinite loop is generated asking for a validation of the server cert.
I would suggest having the client create a .bak file each time it successfully exits (or some other time) and then if on opening the db is corrupted it will open and use the .bak. If that is corrupted, then new client message and stop.
The text was updated successfully, but these errors were encountered: