Akonadi

Troubleshooting Tips

• When reporting problems with the Akonadi server, always include the comprehensive self-test report. This report can be obtained from the self-test dialog which shows up whenever the Akonadi server was unable to start successfully. You also can access this dialog via systemsettings -> Advanced -> Akonadi -> Server Configuration -> Test.

• Starting the Akonadi server manually on the command line can result in additional useful information. This can be done by running akonadictl start on a console. Similar, with akonadictl stop the Akonadi server can be stopped again.

Common Problems

Apparmor

Some distributions using Apparmor have it set up in a way that prevents Akonadi from running its internal database server. This can result in a variety of fuzzy error messages, including but not limited to the following:

• unknown error 255 when running akonadictl
• "DB error: 'Could not open required defaults file: /home/$username/.local/share/akonadi/mysql.conf"

You can solve this by running aa-complain mysqld with root privileges then reload apparmor. On KUbuntu this is:

sudo aa-complain mysqld
sudo /etc/init.d/apparmor reload

Note that you might be using Apparmor even if it does not show up in the process list.

Also note that some distributions ship an additional mysqld binary called mysqld-akonadi which has AppArmor set up correctly. If that's the case on your system and you see this problem nevertheless, there are two possible reasons:

• Akonadi still uses mysqld instead of mysqld-akonadi. You can change that in Systemsettings -> Advanced -> Akonadi -> Server configuration.
• AppArmor is not setup correctly for mysqld-akonadi either. Try running the aa-complain command noted above with mysqld-akonadi instead of mysqld.

---

You will also experience this problem if you are running an encrypted home directory using encryptfs combined with AppArmor as the Akonadi apparmor profile currently does not account for an ecrypted home (common with Ubuntu Jaunty users). Error messages with include:

• dmesg produces:

     ecryptfs_do_create: Failure to create dentry in lower fs; rc = [-13]
     ecryptfs_create: Failed to create file inlower filesystem

• Akonadi will list the following errors:

     Akonadi server process not registered at D-Bus

The fix is to edit the following file "/etc/apparmor.d/usr.sbin.mysqld-akonadi". Below the line:

      @{HOME}/.local/share/akonadi/** rwk,

Add a new line:

      @{HOME}/.Private/** rwk,

Restart apparmor and restart akonadi.

Missing Prerequisite

To use Akonadi you need to have the following packages installed (names might differ depending on your distribution):

• The MySQL server (called mysql on OpenSuse)
• The Qt4 MySQL plugin (called libqt4-sql-mysql on OpenSuse)

If you compile Qt4 yourself, make sure to tell the configure script to build in MySQL support by passing it the '-plugin-sql-mysql' option. If configure cannot locate the necessary MySQL client code (i.e, says "MySQL support cannot be enabled due to functionality tests") then ensure that the corresponding package is installed (typically called [lib]mysql[client]-dev[el]). Also, depending on the install location of the MySQL headers, additional parameters to configure might be needed (eg. -I /usr/include/mysql on OpenSuse).

Environment Setup

The Akonadi server searches for Akonadi agents and resources in the paths defined in the XDG_DATA_DIRS environment variable. If Akonadi complains about not finding agents or resources, check if this variable is set correctly. Also keep in mind that even if set in a current console session, it might not have been set when starting the server. Starting the server manually in the current console session excludes this cause.

Restarting after a previous error

If you had problems starting Akonadi and fixed those (such as a missing package or the Apparmor problem) make sure that the Akonadi server is completely shut down before trying to start it again, by calling akonadictl stop on the command line. You can confirm that it was indeed shut down completely by running akonadictl status.

Under some circumstances the Akonadi server can be stuck in a partially running state after a failure which will prevent the next attempt to start it to fail as well. Please file a bug report if you run into this problem including the self-test report of the initial problem.

Asserts

That's an especially nasty problem that has been confirmed to affect at least Gentoo, Slackware, and Arch users. It is named after MySQL assertions like the following example and is most likely caused by a MySQL protocol mismatch between the MySQL server and the client library or the Qt MySQL driver.

akonadiserver: libmysql.c:4301: setup_one_fetch_function: Assertion `param->buffer_length != 0' failed.

It is extremely hard to diagnose as the assertion mentioned above are only triggered sometimes. Instead you'll get a wide range of weird symptoms:

• ASAP protocol logs show successful creation of objects which are supposedly no longer available when the next commands accesses them again.
• SQL protocol logs show INSERT or UPDATE commands with values that mismatch the corresponding column types and nevertheless succeed.
• SQL protocol logs showing large apparently random record ids which are nevertheless considered valid.

References:

• http://forum.kde.org/viewtopic.php?f=20&t=61738
• http://bugs.gentoo.org/show_bug.cgi?id=267513
• https://bugs.kde.org/202623 (contains a possible solution)