Arch Linux

Please read this before reporting a bug:

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!

FS#41178 - [mariadb] [akonadi] mariadb 10.0.12 breaks akonadi

Attached to Project: Arch Linux
Opened by Karthik Periagaram (karthikp) - Saturday, 12 July 2014, 20:25 GMT
Last edited by Bartłomiej Piotrowski (Barthalion) - Saturday, 26 July 2014, 08:38 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To Andrea Scarpino (BaSh)
Bartłomiej Piotrowski (Barthalion)
Architecture All
Severity High
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 4
Private No



Upgrading to mariadb 10.0.12 breaks akonadi. Upon logging in, akonadi fails to start.

Downgrading to mariadb 5.5.37 fixes these issues and akonadi starts and works as expected.

I'm filing a new bug since an older one ( referencing a different version of mariadb is marked fixed.

I've set the severity to high as this causes akonadi to not function at all.

Additional info:
mariadb version 10.0.12-1 (breaks akonadi)
mariadb version 5.5.37-1 (works well)
akonadi version 1.12.1-2

Steps to reproduce:
* Upgrade. Mariadb 10.0.12 will be installed.
* Log out and back in. All akonadi-based applications (kmail, korganizer, etc.) are non-functional.
This task depends upon

Closed by  Bartłomiej Piotrowski (Barthalion)
Saturday, 26 July 2014, 08:38 GMT
Reason for closing:  None
Comment by Filzmaier Josef (saabzero) - Sunday, 13 July 2014, 11:28 GMT
At my system deleting ~/.local/share/akonadi/mysql.conf solved the problem, without data loss.
Comment by ed tomlinson (edt) - Sunday, 13 July 2014, 12:30 GMT
Here it worked without problems. Best guess is that there is something in older .conf files that mariadb 10.0.12 does not like.
Comment by Daniel (weirddan455) - Sunday, 13 July 2014, 13:45 GMT
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.
Comment by Gustavo E. Conturzo (gconturzo) - Sunday, 13 July 2014, 14:15 GMT
First, read:


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

This worked for me.
Comment by Daniel (weirddan455) - Sunday, 13 July 2014, 14:39 GMT
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)
Comment by Karthik Periagaram (karthikp) - Sunday, 13 July 2014, 15:36 GMT
I can confirm virtually everything in Daniel's ( 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).

Comment by AMM (amish) - Monday, 14 July 2014, 15:58 GMT
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)
Comment by Jörg Schuck (Schmeidenbacher) - Tuesday, 15 July 2014, 13:16 GMT
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.
Comment by Bartłomiej Piotrowski (Barthalion) - Saturday, 26 July 2014, 08:38 GMT
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.