Chromium/Chrome uses a ton of sqlite databases for its storage needs. That’s great – sqlite is a wonderful little database, but one problem with sqlite is if the machine crashes (runs out of battery, etc.) while the database is writing, the database can be in a permanently ‘locked’ state when it comes back up. Chromium still works, but it will complain at startup (“Your profile could not be opened correctly”) and likely some features won’t work correctly. The cure is to dump the database into a new one, which will recover everything, but that can’t be done in-place. I saw some comments saying it’s always the Sync database, for instance, but that was not true in my case. Looking into it, there were 277 -journal files in my profile, and doing each one by hand was out of the question.
So, here’s a little script that will do all that work for you. It’ll find any sqlite journal file in the Chromium profile, run a 3-command pipe to do the rebuild, and then rename the old files to ‘.old’. Edit the script for your profile location and make a backup of your profile first, just in case. Quit chromium first, of course.
From your profile directory, you could run something like this:
find ./ -name "*.old" -exec rm {} \;
to delete the .old files when you’re happy with the outcome. It worked for me, but I still have no idea which file was the problem. It would be great if Chromium could handle the case of a sqlite file needing to be rebuilt – it’s a common enough problem that “just delete your profile” is a crummy workaround, even if Sync will fill in most of the data again.
This was tested with chromium-35.0.1916.153-1.fc20.x86_64.
[Update: 2015-01-10 – lost my profile again when my /home disk filled up (fragile!). This time there were spaces in some of the database names, so the script is updated to shell-escape those]