Chromium + Debian Stretch 9 - Cookies get removed on random startups

Sometimes when Chromium is loaded on startup in Debian Stretch 9 with MATE Desktop I found that it had lost all the cookies, which in turn resulted in that all previous login sessions were gone.

This is very annoying and I began an investigation to find out what was wrong.

Enable Logging

Logging may be enabled with the --enable-logging parameter, and the verbosity can be set with --v=X. I found --v=0 to show what I needed to know.

I made a Bash script to start Chromium with the above, but afterwards I found that there is a simpler way to pass parameters (named flags) to it. Create a file here and name it to what you want:
/etc/chromium.d

Fill it with (check the other files to make sure the syntax still is correct):
export CHROMIUM_FLAGS="$CHROMIUM_FLAGS --enable-logging --v=0"

Now you get a log in:
/home/<your system username>/.config/chromium/chrome_debug.log

Note that this log is overwritten each time Chromium starts. It may be wise to add some code to copy the old log somewhere else into the Chromium startup script created above.

SQL locked

The first problem I found by reading the log was that Chromium had it's SQLite database locked by another process, which resulted in cookie deletions in the database.

I checked my startup programs and noticed that I had two Chromium processes starting, I removed one of them. That seemed to fix the locking. I managed to open multiple pages with only one process start by adding the urls after each other when calling Chromium, like this:
chromium "https://www.example.com/" "https://www.example.com/"

Password store too slow to load

I thought fixing the previous problem was enough. How wrong I was. After a few days I found Chromium starting without cookies again. I found this in the log:

[xxxx:xxxx:xxxx/xxxxx.xxxxx:WARNING:password_store_factory.cc(253)] Using basic (unencrypted) store for password storage. See https://chromium.googlesource.com/chromium/src/+/master/docs/linux_password_storage.md for more information about password storage options.
[xxxx:xxxx:xxxx/xxxxx.xxxxx:ERROR:token_service_table.cc(141)] Failed to decrypt token for service AccountId-xxxxxxxxx
[xxxx:xxxx:xxxx/xxxxx.xxxxx:ERROR:token_service_table.cc(141)] Failed to decrypt token for service AccountId-xxxxxxxxx

I ended the process and started it again. Still no cookies.

It seems like Chromium sometimes starts before the password storage is loaded. And it does not stop there. It uses a basic plaintext (?) fallback to store the cookie data instead, and then next time when it starts then it imports the cookies made when running in basic mode into the password storage, probably completely overwriting the old cookies.

I also found out that the basic password storage method seemed to be reliable. And if you really want to get someones passwords in Chromium you do not need to bother with files anyway. Just open chrome://settings/ and click Passwords and there they are, easily readable as soon as the keyring has been unlocked. So why bother with this failing storage at all and not run the basic one which works?

To always run the basic password storage, update the file with the logging and add or update it with this:
export CHROMIUM_FLAGS="$CHROMIUM_FLAGS --password-store=basic"

Then enjoy the unsafe but persistent cookie storage.