Fixing Duplicate and Stuck Messages in Akonadi

Tags: howtos, linux

« Previous post: Questions to Sharpen a Research Proposal — Next post: A Sustainable Pace Gets You to the … »

One of the perks of being a Linux user is that we often get the chance to dive into obscure issues with our software. Sometimes, we even get to fix them! This here is a brief description of my struggles in removing messages from my kmail or kontact outboxes.

The error that kmail shows in its status line is something along the lines of ‘Unable to fetch item from backend … [LRCONFLICT].’ After reading a bunch of discussion threads and grappling with Akonadi tooling, I arrived at the following solution:

1. Close all applications that use Akonadi, such as kmail or kontact. Make sure there are no processes around:

    $ ps aux | grep kontact
   

2. Run a consistency check on the internal database:

    $ akonadictl fsck 
   

   Optionally, if you want to see how many problematic items there are, you can also search the output of that tool:

    $ akonadictl fsck 2&>1 | rg Found
    Found 19472 external files.
    Found 19472 external parts.
    Found no unreferenced external files.
    Found 0 parts to be moved to external files
    Found 0 parts to be moved to database
    Found 3 collections without RID.
    Found 1 items without RID.
    Found 0 dirty items.
   

   We are interested in the items without an RID, i.e. without a remote ID. These are the items or messages for which Akonadi has no reference any more.

3. Next, let us delete these items. For this, we need to connect to the SQL database run by Akonadi. In my case, this works using the following command:

    $ mysql --socket=/run/user/1000/akonadi/mysql.socket
   

   You can figure out the appropriate socket via:

    $ ps aux | rg mysql | rg socket  
    bastian    92718  0.0  0.8 3871628 285900 ?      Sl   Jul28   1:32 /usr/bin/mysqld --defaults-file=/home/bastian/.local/share/akonadi/mysql.conf --datadir=/home/bastian/.local/share/akonadi/db_data/ --socket=/run/user/1000/akonadi/mysql.socket --pid-file=/run/user/1000/akonadi/mysql.pid
   

   Once you are connected to the data base, you need to switch to the akonadi table by issuing use akonadi;. Here’s the transcript of my session so far:

    Welcome to the MariaDB monitor.  Commands end with ; or \g.
    Your MariaDB connection id is 1500
    Server version: 10.8.3-MariaDB Arch Linux
   
    Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others.
   
    Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
   
    MariaDB [(none)]> use akonadi
    Reading table information for completion of table and column names
    You can turn off this feature to get a quicker startup with -A
   
    Database changed
    MariaDB [akonadi]> 
   

   Finally, and this is somewhat arcane, we need to delete all items with an undefined RID.

    MariaDB [akonadi]> delete from pimitemtable where remoteid is NULL;
   

4. Afterwards, we can CTRL + D out of the SQL console and voilà, the messages should be gone the next time you start your application.

All in all, I am glad I got this to work, and I learned a lot from reading about the architecture of Akonadi. Let me close this post with a few philosophical considerations (feel free to stop reading here).

All right, now that we are among friends, brace for some ponderous thoughts.

I cannot fail to notice that software appears to have become massively complex and somewhat brittle. That is not denigrate the valiant efforts of the KDE developers; they are doing an excellent job at providing me with a simple-to-use and powerful desktop environment. Yet, I sometimes feel that this complexity can be quite overwhelming for normal users. If you just care about writing an e-mail, why should you have to deal with these database incantations? I happen to like them—mostly as a distraction from the things I should be doing instead—but surely, this is not what we can expect any user to do.

Notice that this is not restricted to open source software; quite the contrary! With open source software, we, i.e. the more knowledgeable users, often have a way to contact developers directly in case something goes awry. With a commercial product, we are forced to scour some official-looking forums where a customer representative will use a few placating words just to never get back to us… And quite often, other users, trying to be helpful, will essentially just tell us to reinstall our software, reconfigure the user account, or something equally drastic.

I have no idea how to move forward—but I would wish for a future in which software is made more robust, making it possible to recover from these intermediate, weird, and unspecified states without user invention.

Maybe advances in artificial intelligence will get us there. Until then, I hope your software never breaks!