Ubuntu
akonadi package

  1. Bug #578357
  2. Comment #19

Comment 19 for bug 578357

Revision history for this message
In , Cubranic-w (cubranic-w) wrote :

Version: (using KDE 4.4.2)
OS: Linux
Installed from: Ubuntu Packages

I originally reported this bug in Ubuntu Launchpad: https://bugs.launchpad.net/ubuntu/+source/akonadi/+bug/578357

I am opening it here as a wider issue: Akonadi is very fragile in the face of mysql startup problems, and that has a knock-on effect of preventing basic user applications (mail, PIM) from running.

The most visible symptom of the problem was that after starting up KMail, I would get an error dialog stating that Akonadi is not running. After closing the dialog, the app would close also.

I started investigating, and got voluminous, but not very helpful error output when running 'akonadictl start' from the command line. (I'll attach a copy.) Further poking and twiddling with apparmor and other workarounds suggested in various bugs and forums was unsuccessful. Eventually, I stumbled upon mysql.err in ~/.local/share/akonadi/db_data/ with the following contents:

100519 9:49:38 [Note] Plugin 'FEDERATED' is disabled.
 InnoDB: Error: log file ./ib_logfile1 is of different size 0 0 bytes
 InnoDB: than specified in the .cnf file 0 67108864 bytes!
 100519 9:49:38 [ERROR] Plugin 'InnoDB' init function returned error.
 100519 9:49:38 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
 100519 9:49:38 [ERROR] Unknown/unsupported table type: innodb
 100519 9:49:38 [ERROR] Aborting
100519 9:49:38 [Note] /usr/sbin/mysqld-akonadi: Shutdown complete

File 'ib_logfile1' was indeed of size zero. Deleting it and 'ib_logfile0', and then restarting 'akonadictl' seemed to fix the problem and I now have a working mail reader.

I don't know how the log file got corrupted, but the system should be more robust than that. I mean, having a zero-size or corrupted log file does not need to be an unrecoverable error!

It's completely reasonable in such a situation to delete it and proceed with startup. The database should still be in a consistent state, and the worst that could happen is that the last few transactions are missing. Or at the very least notify the user what the real problem is. As it is, akonadi server's output is utterly unhelpful, and it took me forever to find Akonadi's mysql.err, where the problem was actually clearly identified.