Curtis Farnham

I’ve had a little more shakedown time with KDE 4.2 now.  This morning I decided to tackle a problem I was encountering every time I logged in, involving Akonadi and MySQL.  Here’s what the error window looked like:

This error was particularly annoying because the message window would only appear for about 10 seconds and disappear, only to reappear and then disappear another couple of times as the rest of my KDE session was restored.

First of all, what is Akonadi?  The idea is that in KDE4, the developers wanted to have a common API that KDE PIM applications could access data from.  This includes calendar events, To-Do’s, and stuff like that.  It makes sense; KDE is all about common libraries and API’s, and when you have a bunch of applications using the same data, there’s no sense in having each one re-implement the same functions for retrieving and updating this data.

The problem with Akonadi right now, though, is that it absolutely requires MySQL to be installed.  I read that there are plans in the works to make it support other databases, but apparently no other database has quite the set of features and stability that the Akonadi developers felt were required at this time.  Hmph.

Back to my error messages.  The main one that troubled me was, “MySQL server default configuration not found.”  I began Googling and was surprised to find extremely sparse information about Akonadi.  I’m sure that’ll change as others face this error and get accustomed to KDE4.  But for now, what’s a geek like me to do?

Well, I dug through the list of files that Akonadi installed on my machine (that is, /var/db/pkg/app-office/akonadi-server-1.1.1/CONTENTS) and found the following file:

/usr/share/config/akonadi/mysql-global.conf

But… but… where does this file belong?  More Googling, this time for “mysql-global.conf”.  I found a forum posting that suggested I could put this in /home/<my-username>/.config/akonadi/ .  It worked!

[Note: If you haven't used any KDE4 PIM apps in your user account yet, this should be all you need.  Just log out and log back in, and it should work.  I, however, continued to have the problems described below because I had already used Kontact and a handful of the apps it contains.  Not sure why, but anyway...]

Or so I thought.  Upon logging out and logging back in, the same Akonadi error window came up.  The previous error message was gone, but now a different error was holding up the show: “MySQL server configuration not found or not readable.”  Great!  Now what?

I then happened upon an Akonadi configuration module in:

System Settings -> Advanced -> Akonadi configuration

Opening it up led to a two-tab interface that happily showed me a red icon with an “x” through it and a message indicating Akonadi wasn’t running.  Thank you, Mr. Computer.  I could have guessed that much.

The second tab, “Akonadi Server Configuration”, gave me some clues, and a “Test” button that would show the same error window I had encountered upon KDE login, but it stayed put without disappearing on me.  Getting closer…

There are basically two options for Akonadi Server.  It can use an internal MySQL server, for which all it needs to know is the location of the MySQL binary executable.  (Rather, I think it executes mysqld on its own, using the configuration in mysql-global.conf.)  Or, it can use an External MySQL server, for which it needs the standard MySQL connection stuff: Database Name, Host, Username, and Password.

I didn’t want to use an External MySQL server, so I was left with guessing why the Internal one didn’t work.  In my Googling, I had determined that Akonadi keeps its MySQL socket and data files in /home/<my-username>/.local/share/akonadi/ .  Reading through ./db_data/mysql.err showed me Akonadi was trying to connect to its internally controlled MySQL daemon with the username of my system login account.  But there was no MySQL user set up with that name! Furthermore, it was trying to connect to a database with a name of akonadi.  Again, no database existed by that name.  Here’s where some weirdness set in, and I’m not actually sure what solved the problem.  But I’ll tell what I did.

I confess that before I understood that Akonadi could use an Internally controlled MySQL daemon instance, I spotted an empty Username and Password config option in /home/<my-username>/.config/akonadi/akonadiserverrc .  I filled these out with the MySQL admin user and password info, just guessing that this might solve the problem.  I also created a database called “akonadi” and giving it world-writable permissions (identical to the “test” database MySQL always installs.)  After doing this and logging in/out a couple of times testing other things (which I don’t quite remember enough to explain), Akonadi server started working.  But it’s strange because it never wrote anything to the “akonadi” database.  And it’s still configured to use the Internal MySQL connection, which means it technically isn’t even connecting to the same mysqld instance under which that “akonadi” database existed.

Anyway, after it began working, the next time I logged in to KDE, a new window popped up saying it was migrating various pieces of KDE PIM info over to Akonadi.  And no problems since.  Great!  (I just wish I knew how I got here…)

-Curtis

Related posts:

1. [Updated] KDE 4 Application Crashing One hiccup I encountered when installing KDE 4 on my...
2. Upgrade to KDE 4.2 I upgraded to KDE 4.2 this evening.  It’s definitely an...
3. Trying out KDE 4.1.4 Ever since the first public beta releases of KDE 4.0,...
4. No spellcheck in OpenOffice 3? I was typing up a document today in OpenOffice Writer,...
5. KDE 4.2, sets, and Portage 2.2 hard masked I ran my typical system update this morning, an emerge...

curtisdf Gentoo Linux, Office Productivity Akonadi, MySQL