I'm running Kmail 4.14.10 on a FreeBSD 11.1 system and using IMAP to access a Dovecot mailbox on localhost.

I have a problem with Kmail hanging permanently while syncing mailboxes on startup. The problem is intermittent but persists between reboots and has been like this for a few weeks now but has occasionally been known to rectify itself. When it does work things can be fine for anything between a few minutes and several weeks before the problem returns.

I'm confident that the mailbox isn't corrupted because I can access if from the same PC using Thunderbird or Claws. In fact I can even access the same mailbox with Kmail if I login to the same PC as a different user.

This leads me to suspect that one of the config files used by Kmail is corrupted. As a workaround I can restore access to the mailbox by deleting its account in Kmail and then creating a new account for it. The problem with this workaround is that I have 147 folders for that mailbox, many of which have specific properties so setting things up again is tedious.

Ideally I'd like to be able to track down and fix the source of the problem or as a second best option is there any way I can backup all the folder properties and then restore them after recreating the mail account?

howgill wrote:I'm running Kmail 4.14.10 on a FreeBSD 11.1 system and using IMAP to access a Dovecot mailbox on localhost.

I have a problem with Kmail hanging permanently while syncing mailboxes on startup. The problem is intermittent but persists between reboots and has been like this for a few weeks now but has occasionally been known to rectify itself. When it does work things can be fine for anything between a few minutes and several weeks before the problem returns.

I'm confident that the mailbox isn't corrupted because I can access if from the same PC using Thunderbird or Claws. In fact I can even access the same mailbox with Kmail if I login to the same PC as a different user.

This leads me to suspect that one of the config files used by Kmail is corrupted. As a workaround I can restore access to the mailbox by deleting its account in Kmail and then creating a new account for it. The problem with this workaround is that I have 147 folders for that mailbox, many of which have specific properties so setting things up again is tedious.

Ideally I'd like to be able to track down and fix the source of the problem or as a second best option is there any way I can backup all the folder properties and then restore them after recreating the mail account?

You may try the following:

1. Rebuild akonadi storage: viewtopic.php?f=215&t=143249

2. If the above does not work start with a pristine installation: backup your configuration, delete anything referring to akonadi and kmail. When configuring kmail stay away from Account wizard for KMail. Add an IMAP account. Test for functionality. Restore from backup only if you know what you are doing.

As suggested, I stopped akonadi, deleted .local/share/akonadi/ (or rather I moved it out of the way elsewhere) and restarted akonadi. This fixed the indexing problem and I could access all my emails but there were some adverse side effects. Most of my folder properties for sender identity and expiry were lost, many of the actions associated with filter rules were lost and all my Knotes vanished.

I've restored the original .local/share/akonadi/ to recover my Knotes with the intention of continuing using Claws mail as a temporary alternative until I manage to resolve the issue.

A few days after that happened many packages on my system were upgraded and I discovered that Kmail had started working again (using my original copy of .local/share/akonadi/). Although neither akonadi nor kdepim were upgraded there were upgrades to qt4-gui, qt4-network, qt4-sql, qt4-xml and soprano which akonadi depends on and to qt4-opengl and qt4-script which kdepim depends on so I suppose one or more of these might be relevant.

This isn't the first time that Kmail has 'come to life' again and many of these instances have been shortly after packages had been upgraded. I'll see how long I can keep going this time before it dies again.

However, on being able to use Kmail again, I found that the corruption of the folder properties and filter rules was still present so I'm assuming that rebuilding the akonadi storage must have affected some other config files.

howgill wrote:As suggested, I stopped akonadi, deleted .local/share/akonadi/ (or rather I moved it out of the way elsewhere) and restarted akonadi. This fixed the indexing problem and I could access all my emails but there were some adverse side effects. Most of my folder properties for sender identity and expiry were lost, many of the actions associated with filter rules were lost and all my Knotes vanished.

I've restored the original .local/share/akonadi/ to recover my Knotes with the intention of continuing using Claws mail as a temporary alternative until I manage to resolve the issue.

A few days after that happened many packages on my system were upgraded and I discovered that Kmail had started working again (using my original copy of .local/share/akonadi/). Although neither akonadi nor kdepim were upgraded there were upgrades to qt4-gui, qt4-network, qt4-sql, qt4-xml and soprano which akonadi depends on and to qt4-opengl and qt4-script which kdepim depends on so I suppose one or more of these might be relevant.

This isn't the first time that Kmail has 'come to life' again and many of these instances have been shortly after packages had been upgraded. I'll see how long I can keep going this time before it dies again.

However, on being able to use Kmail again, I found that the corruption of the folder properties and filter rules was still present so I'm assuming that rebuilding the akonadi storage must have affected some other config files.

To my experience corruption of the folder properties and filter rules is caused by akonadi. Corruption always occurs before deleting the storage directory. Storage is readily created again upon invoking akonadi. It runs for several weeks without causing any problems until corruption occurs again for some reason unknown to me.

With the akonadis causing heavy load again two days later deleting .local/share/akonadi/ and recreating these data would not do the trick again. Thus I deleted the following:

Code: Select all

karl@erlangen:~> ll -rt .config/akonadi/agent_config_akonadi*changes.dat
-rw-r--r-- 1 karl users 16 27. Feb 16:22 .config/akonadi/agent_config_akonadi_birthdays_resource_changes.dat
-rw-r--r-- 1 karl users 16 27. Feb 16:22 .config/akonadi/agent_config_akonadi_akonotes_resource_0_changes.dat
-rw-r--r-- 1 karl users 16 27. Feb 16:22 .config/akonadi/agent_config_akonadi_ical_resource_0_changes.dat
-rw-r--r-- 1 karl users 16 27. Feb 16:22 .config/akonadi/agent_config_akonadi_followupreminder_agent_changes.dat
-rw-r--r-- 1 karl users 16 27. Feb 16:22 .config/akonadi/agent_config_akonadi_indexing_agent_changes.dat
-rw-r--r-- 1 karl users 16 27. Feb 16:22 .config/akonadi/agent_config_akonadi_maildir_resource_0_changes.dat
-rw-r--r-- 1 karl users 16 27. Feb 16:22 .config/akonadi/agent_config_akonadi_contacts_resource_0_changes.dat
-rw-r--r-- 1 karl users 16 27. Feb 16:22 .config/akonadi/agent_config_akonadi_maildispatcher_agent_changes.dat
-rw-r--r-- 1 karl users 16 27. Feb 16:22 .config/akonadi/agent_config_akonadi_archivemail_agent_changes.dat
-rw-r--r-- 1 karl users 16 27. Feb 16:22 .config/akonadi/agent_config_akonadi_newmailnotifier_agent_changes.dat
-rw-r--r-- 1 karl users 16 27. Feb 16:22 .config/akonadi/agent_config_akonadi_notes_agent_changes.dat
-rw-r--r-- 1 karl users 16 27. Feb 16:22 .config/akonadi/agent_config_akonadi_migration_agent_changes.dat
-rw-r--r-- 1 karl users 16 27. Feb 16:22 .config/akonadi/agent_config_akonadi_mailfilter_agent_changes.dat
-rw-r--r-- 1 karl users 16 27. Feb 16:22 .config/akonadi/agent_config_akonadi_sendlater_agent_changes.dat
karl@erlangen:~>

I frequently upgrade the system without corruption occurring. Make sure to stop akonadi before updating the system.

Well Kmail 'came back to life' on its own accord after a few weeks and I got a couple of months use before it started hanging again. As before, attempting to delete files in .local/share/akonadi failed to cure the problem and destroyed my knotes and calendar.

I then restored my config files to the state immediately before deleting them and tried to fix it using a suggestion at https://mail.kde.org/pipermail/kdepim-u ... 00546.html. I used akonadiconsole to clear the cache for the folder where kmail's indexing had hung and this appears to have cured the problem. Whether or not this will work next time remains to be seen but I'll keep my fingers crossed.

howgill wrote:Well Kmail 'came back to life' on its own accord after a few weeks and I got a couple of months use before it started hanging again. As before, attempting to delete files in .local/share/akonadi failed to cure the problem and destroyed my knotes and calendar.

I then restored my config files to the state immediately before deleting them and tried to fix it using a suggestion at https://mail.kde.org/pipermail/kdepim-u ... 00546.html. I used akonadiconsole to clear the cache for the folder where kmail's indexing had hung and this appears to have cured the problem. Whether or not this will work next time remains to be seen but I'll keep my fingers crossed.

Happened to fix Kmail/Akonadi again yesterday. When the Akonadis started their ***turbations I deleted anything of name kmail2* and akonadi* unless absolutely needed as well as ./.local/share/akonadi. Then I searched for inappropriate folders like .../cur/cur, tmp/cur new/cur and so on and deleted them too. I also deleted some corrupted mails, identified by a file size less than 100 bytes.

Finally I am left with the following:

Code: Select all

karl@erlangen:~> find . -name kmail2*
./.config/kmail2rc
karl@erlangen:~> find . -name akonadi*
./.config/akonadi
./.config/akonadi/akonadiserverrc
./.config/akonadi/akonadiconnectionrc
./.config/akonadi_contactrc
./.config/akonadi-migrationrc
./.config/akonadi_akonotes_resource_0rc
./.config/akonadi_maildir_resource_0rc
./.config/akonadi_mailfilter_agentrc
./.config/akonadiconsolerc
./.config/akonadi_indexing_agentrc
./.config/akonadi_newmailnotifier_agentrc
./.config/akonadi-firstrunrc
./.local/share/akonadi
./.local/share/akonadi/akonadictl.error.old
./.local/share/akonadi/akonadi_control.error.old
./.local/share/akonadi/db_data/akonadi
./.local/share/akonadi/akonadiserver.error.old
./.local/share/akonadi_migration_agent
./.local/share/kxmlgui5/akonadiconsole
karl@erlangen:~>

Running akonadictl fsck is now blazingly fast (real 0m0,120s user, 0m0,015s, sys, 0m0,014s) on a collection of some 25.000 maildir files and no longer identifies any irregularities. Load averages decreased from some 1.90, 1.4, 1.5 to: 0.10, 0.14, 0.10.