Below are some of my thoughts based on my digging around in Akonadi Console:

• RID seems to stand for "Remote Identifier,"[1] which is a pointer or link to the remote file or folder associated with the item at issue.
• If my assumption above is correct, you can view the Remote Identifier of a item or collection by doing the following:
  
  1. Run Akonadi Console
  2. Click "Browser" tab
  3. Right click on folder/collection (i.e. Search) of choice
  4. Click "Folder Properties."
  5. Select "Internals" tab.
  6. "Identfier" should match the collection "id" value from your akonadictl fsck output, and the "Remote Identifier" field will be blank if the akonadictl fsck output says "...has no RID"
• Based on the above, "Collection 'Search' (id: 1) has no RID" means that there is no link to a physical folder that contains your searches. This seems logical since your searches are really a collection of RIDs that exist elsewhere. The same should apply to the collections "Last Search" and "Poker League." The more puzzling collection that has no RID is "akonadi_mbox_resource_1." I am guessing that you may have imported an mbox file at some point in time and the file was later deleted or something of that kind.
• To delete the collections/folders that have no RID do the following:
  
  1. Run Akonadi Console
  2. Click "Browser" tab
  3. Right click on folder/collection (i.e. Search) of choice
  4. Click "Delete Folder."
  5. Note: It seems that you are not allowed to delete the "Search" collection/folder; however, you should be able to delete all its subfolders.
• If the deductions above are true (they most likely are), then the "Item '###' has no RID" suggests that you have an item (i.e. an email, calendar event, contact, etc.) that has a record but no physical file linked to or associated with it.
• Deleting Items that have no RID by GUI is convoluted. Nevertheless, the first part is to locate what folder/collection the item at issue is in:
  
  1. In Akonadi Console
  2. Click "DB Browser" tab
  3. In the drop-down option list, select "pimitemtable" and click "Refresh."
  4. Sort the resulting table by "remoteid," by clicking on the "remoteid" table header. This should list all items with a blank "remote id" first.
  5. You should now be able to look at the corresponding "collectionid" column to identify the collections/folders where these items with no RIDs live.
• The second step will be to select the pertinent collection from the "Browser" tab of Akonadi Console, find the id, right click on it, and delete it.
• Note: (See Update below) If you know of some way to access the the akonadi mysql db directly using the mysql client, you should be able to delete all the problematic items by running something like:
  

  Code: Select all

  delete from pimitemtable where remoteid="";

• Whereas I do not know what the "Item '###' has RID and is dirty" means, I think it may mean that the RID is pointing to a location/file that no longer exists on the drive. I have no fsck outputs of this kind, so guess is all I can do here.

Sorry for the super long explanation, but hope it helps

[1] and "Remote id" in the Model: "Generic" view of the "Browser" tab in Akonadi Console

UPDATE
To delete all the "Item '###' has no RID" items directly from the mysql db over cli do the following:

1. Find the socket information for your akonadi mysql db by running the dollowing form the command line
   

   Code: Select all

   ps aux|grep mysqld

   
   You should see output similar to
   

   Code: Select all

   user  2152  0.3  2.0 801520 246368 ?       Sl   Sep14  30:26 /usr/libexec/mysqld --defaults-file=/home/user/.local/share/akonadi/mysql.conf --datadir=/home/user/.local/share/akonadi/db_data/ --socket=/tmp/akonadi-user.lnWui2/mysql.socket --pid-file=/tmp/akonadi-user.lnWui2/mysql.pid


2. Connect to the akonadi mysql database via its socket (obtained from "--socket=" above)
   

   Code: Select all

   mysql --socket=/tmp/akonadi-user.lnWui2/mysql.socket


3. Select the akonadi database
   

   Code: Select all

   use akonadi;


4. Delete the problem items
   

   Code: Select all

   delete from pimitemtable where remoteid="";
delete from pimitemtable where remoteid is NULL;
quit


bugzy wrote:Delete the problem items

Code: Select all

delete from pimitemtable where remoteid="";
delete from pimitemtable where remoteid is NULL;
quit


Be careful though.

It's true that this should get rid of the warnings about items with no RID.

But as they have no RID, they haven't been "uploaded" (synced) to the actual storage yet and only exist in the database.
IOW, you will lose data. The same danger also exists if you delete the cache in akonadikonsole or wipe out the database completely, of course.
(whether they are important mails or maybe just bogus entries is a different story though)

Hey,

thanks for all the suggestions! This seems to be well beyond what a typical user might be doing.

Do you know if this is a new problem? I first noticed it on my jessie system about a month or two ago. I only use POP and at first just renaming the user akonadi folder worked, but no longer.

Kmail worked well for years before then, did some update perhaps mess things up? Does anyone know if the problem is still present in debian 9?

It has made Kmail unusable.

Chris

chrisn asked:

This seems to be well beyond what a typical user might be doing.
Do you know if this is a new problem?

These corrective procedures are beyond the typical user. The Open Source World depends on the users capable of collecting detailed symptoms of problems, and results of advanced corrective procedures to help these developers understand what is happening. Software these days has a multi-layered architecture, and the developer/user who can isolate the layer or interface between two layers that is the root cause of the problem is worth his weight in gold. Kmail itself depends on Akonadi, and Mysqld; along with the kernel, file system, and the OS utilities.

I would try to answer the question how long has the "problem" been around, but I cannot. I have seen the generic error message "Kmail resource is broken" for over three years. I understand the reasons for generic error messages. The Kmail developers could have fixed the "problem" I saw three years ago. And now a different "problem" is causing the same error message.

I want to be one of the "beyond typical" users assisting the developers and other "beyond typical" users to make Open Source better.

I apologise if this is seen as a mild rant.

Somehow in using these procedures, logging out, and logging in; Kmail refused to start and reported that Akonadi was not running.

"akonadictl status" reported that Akonadi was not running. "akonadictl start" reported that Akonadi was not started successfully because of a error in a socket file. The socket file had a name like /tmp/akonadi-hank.aEtI9E/mysql.socket. In the folder name "hank" is my user id on the system, and "aEtI9E" appears to be a random string. The socket name "mysql.socket" might also be either "akonadiserver-cmd.socket" or "akonadiserver-ntf.socket". All three socket files existed.

I deleted the folder "/tmp/akonadi-hank.aEtI9E/." and all three of its socket files. Then Akonadi, and Kmail could be started successfully.

No need to appologize, but you could have saved yourself the lecture.

I did find one bug-report (https://bugs.kde.org/show_bug.cgi?id=377344) that seemed to describe my problem, especially since I have been using some new filters, but deleting all my filters did'nt help. I also deleted all my Kmail config files and the .local/share/akonadi folder and tried to set up Kmail again from scratch (with my old Mail directory). Nothing, it is still unusable. I'm considering moving to Debian 9.0 anyway, but I'm a little woried that the problem will still be there. If so, bye-bye Kmail aber 14 Years...

hankivy wrote:chrisn asked:

This seems to be well beyond what a typical user might be doing.
Do you know if this is a new problem?

These corrective procedures are beyond the typical user. The Open Source World depends on the users capable of collecting detailed symptoms of problems, and results of advanced corrective procedures to help these developers understand what is happening. Software these days has a multi-layered architecture, and the developer/user who can isolate the layer or interface between two layers that is the root cause of the problem is worth his weight in gold. Kmail itself depends on Akonadi, and Mysqld; along with the kernel, file system, and the OS utilities.

I would try to answer the question how long has the "problem" been around, but I cannot. I have seen the generic error message "Kmail resource is broken" for over three years. I understand the reasons for generic error messages. The Kmail developers could have fixed the "problem" I saw three years ago. And now a different "problem" is causing the same error message.

I want to be one of the "beyond typical" users assisting the developers and other "beyond typical" users to make Open Source better.

I apologise if this is seen as a mild rant.