2015-08-11

Nuking Akonadi data to fix KOrganizer crash

I updated my Lubuntu Linux system recently and afterwards KOrganizer started to crash.  Well, not exactly crash.  More like KOrganizer refuses to work when it finds that Akonadi has stopped working.

Symptoms:  Open KOrganizer only to be greeted by a big red "X" icon and the words "The Akonadi personal information management service is not operational."  Click on the "Details" button and the "Akonadi Server Self-Test" window says I have these errors:

  • MySQL server log contains errors
  • Akonadi control process not registered at D-Bus.
  • Akonadi server process not registered at D-Bus.
  • No resource agents found.
  • Current Akonadi server error log found.
  • Previous Akonadi server error log found.
Here's my fix for it.
And by fix I mean I found out enough just to nuke the underlying data so that Akonadi can start properly, so that KOrganizer can then also start properly.

This will result in data loss if you didn't backup your data in the past.  Proceed at your own risk.

Apparently, KOrganizer (a calendaring program) uses Akonadi for storing its calendaring and contact information.  Akonadi in turn uses MySQL as its underlying database storage.

Fortunately, I keep all my calendaring in easy to backup iCal files so I had them easy for backup purposes (and easy to salvage in case of something like the current situation occurring, because to be honest, I haven't done a backup of those files in ages).

Verify the symptoms:
Open a terminal and execute akonadictl status.

That told me the Akonadi Control and Server are stopped.  So try starting it with akonadictl start.

It resulted in a lot of error codes and it stopped trying when it found:
"akonadiserver" crashed too often and will not be restarted! 
Scroll through the error codes and noticed some MySQL errors related to executing /usr/sbin/mysqld-akonadi and such.  Fixing the errors at the source is way too much work for me, especially when the actual valuable data was backed up anyway.  So let's fix it the sort of lazy way.

The fix: nuke the underlying user data.  Let Akonadi and KOrganizer reconstitute user data files from scratch.  You had best have back ups of all valuable data beforehand though!

When scrolling through the error codes, notice the arguments to mysqld-akonadi mentions some --defaults-file and --datadir, etc., on an "arguments" line.  It shows that my data were stored in  /home/YourHomeUserName/.local/share/akonadi.

So open up ~/.local/share/.  Zip and backup that "akonadi" folder (in case you need it in the future or something --- I did mention to backup all your stuff).  Then delete the broken "akonadi" folder.

Start KOrganizer again.  It'll automatically start the Akonadi server, which will reconstitute a blank "akonadi" user data folder.

Now retrieve your calendar backups and re-import them into KOrganizer.

PS:  There's probably a very smart way to fix the problem without nuking Akonadi's user data and potentially losing your valuable data.  I didn't have to care because I had backups of everything I care about, so I could afford to nuke Akonadi's user data from orbit.  It's too bad KOrganizer and Akonadi doesn't have some easy automated way to repair its own data stores as best as it could or at least a (rather dangerous) button to nuke its own data.  At least that way unskilled Linux users who doesn't know how to fix their system could "start over".  As it is, an unskilled Linux user would simply have to stare at a broken KOrganizer program.

1 comment:

meow said...

In July of 2021, this is still a perfect solution.