Arch Linux

At my system deleting ~/.local/share/akonadi/mysql.conf solved the problem, without data loss.

Here it worked without problems. Best guess is that there is something in older .conf files that mariadb 10.0.12 does not like.

I saw this bug before I upgraded so I did a "cp .local/share/akonadi/mysql.conf broken.conf" and then ran my "pacman -Syu" After a restart, akonadi broke like you reported. I deleted the ~.local/share/akonadi/mysql.conf file, restarted KDE to let it regenerate that file, and it fixed it. But the strange part: "diff broken.conf .local/share/akonadi/mysql.conf" shows no changes! Even stranger, if I manually downgrade to the older mariadb, mariadb-clients, and libmariadbclient I can no longer reproduce the bug. I can delete the mysql.conf file, let akonadi reproduce it with the old mariadb, and I can "pacman -Syu" to the new version with no problems and without having to delete mysql.conf again.

I guess akonadi does *something* to fix itself upon realizing there's no mysql.conf that it doesn't do otherwise even though there are no changes in the resulting mysql.conf itself. What that *something* is... I have no clue.

Hola!!!
First, read: https://www.archlinux.org/news/mariadb-100-enters-extra/

Then:

$ sudo systemctl restart mysqld.service
$ sudo mysql_upgrade
$ mysql_upgrade -h localhost -u root -p
$ sudo systemctl restart mysqld.service

This worked for me.

Did you restart KDE? If not, akonadi is likely still using the old version of mariadb. Akonadi doesn't use the systemd service. It creates its own mysqld process owned by the local user and with databases in ~.local/share/akonadi I believe those commands will only affect the main database in /var/lib/mysql (not used by akonadi)

I can confirm virtually everything in Daniel's (https://bugs.archlinux.org/task/41178#comment125307) comment. It matches my observations *exactly*.

1. The initial upgrade caused all akonadi-based applications to fail at start (I did restart because there was a kernel upgrade as well). Something I didn't mention as part of this bug report is that amarok also complained about the update and showed zero songs in the local collection.
2. I wasn't sure I could delete ~/.local/share/akonadi/mysql.conf and NOT lose data, so I left everything well enough alone.
3. I don't recall if I restarted or logged out and back in at this point. It's likely I just logged out and back in. It did NOT fix this issue.
4. So, I downgraded to 5.5.37 and restarted.
5. That brought back all the akonadi-based applications.

6. Today, I saw the comments on the bug report and decided to try again. I upgraded everything (pacman -Syu)
7. I made a copy of ~/.local/share/akonadi/mysql.conf
8. I logged out and back in and akonadi-based applications continued to work.
9. I rebooted. No issues. Confusion.

10. Diffing against the current mysql.conf shows NO differences.
11. Diffing against my backups (several of them, going all the way back to January 2014) shows no differences either.

And I can't reproduce this issue anymore, again, as Daniel describes.

Summary: To paraphrase Daniel's comment, Akonadi does *something* to fix itself and it's not reflected in mysql.conf.

The magic step is (very likely) multiple reboots.

P.S. Gustavo, thanks for those commands. I simply didn't know the arguments to provide for mysql_upgrade. Simply running mysql_upgrade as non-root didn't work and complained about no running mysql processes or something like that. As Daniel points out, akonadi doesn't use the systemd service, so I just didn't know how to use mysql_upgrade to fix the akonadi databases (and I didn't know what the database files look like, either, so I was very worried about losing data).

I think right solution is not to simply run mysql_upgrade.

But it should be run as this:
mysql_upgrade --socket=/tmp/akonadi-userid.XXXXXX/mysql.socket

Where userid is your userid and XXXXXX varies on each KDE restart

Also try this: (Works without deleting mysql.conf but bit lengthy and probably more compatible with arch news link about MariaDB)
https://bbs.archlinux.org/viewtopic.php?pid=1435932

In my case it was mariadb that was failing to start.
~/.local/share/akonadi/akonadiserver.error contained this neat bit of information for me:

Database process exited unexpectedly during initial connection!
executable: "/usr/bin/mysqld"
arguments: ("--defaults-file=/home/schmeidenbacher/.local/share/akonadi/mysql.conf", "--datadir=/home/schmeidenbacher/.local/share/akonadi/db_data/", "--socket=/tmp/akonadi-schmeidenbacher.oO3vPL/mysql.socket")
stdout: ""
stderr: ""
exit code: 1
process error: "Process operation timed out"

I tried to start it from the command line with the given parameters, and it simply failed immedeatly. No mysqld service was running on my machine at that time.

I moved the mysql.conf to broken.conf and tried to start it again. And lo and behold, the magic happened, it started. I shut it down again, and tried to access Korganizer. Which in turn started the mysql server again and simply worked. The mysql.conf file has been regenerated, and as mentioned above, has no differences with the previous one.

Since then i can stop and start akonadi at my leisure again without any errors.

I then ran mysql_update with the parameters given in the error message, which checked my tables.

I have added a link to amish's post to the news page. I agree that simple "mysql_upgrade --socket=/tmp/akonadi-userid.XXXXXX/mysql.socket" almost always will fix the problem, but better safe than sorry, and amish mentions it. Closing.