Agree, but meanwhile i tried this update several times on the prod system and regardless of re-login or reboot it didn’t work.
OTOH, on the virtual test system it works from the first run and continued to operate normally on every boot. Not the case on the prod system since today. I’ll see if this will survive the next reboot. 
Had an odd situation with this this morning. My mail appeared to download normally, but did not appear in my mail folders. I rebooted and, surprisingly, akonadi started normally, but the mail still did not appear in kmail. I seem to have solved the mail not appearing problem by going into kmail settings and editing each of my accounts and saving them. After that, the mail appears to download normally and go into the proper folders. I’m convinced that the problems are related and might have something to do with the maildir resource crash that someone else reported.
Has this a report at KDE bugs?
It has: https://bugs.kde.org/show_bug.cgi?id=361157. But as it seems there is not much interest - mainly for reasons like: “works for me”, or “I don’t understand this bug” … (See there).
With the last updates, seems much better. Can anyone confirm it?
Well, I never had a problem in the first place…
But I suppose you mean the KDE Frameworks5 updates?
KDE:Applications 16.04.1 has not been published yet, I did that now, so expect another update… 
As of today i can only confirm that my virtual test system is not broken after the latest Plasma and Frameworks5 updates.
Before installing these updates I tried to mirror my prod system on the virtual one (using the same repos, same packeges, verifying the versions, same config, if possible…). There was only one situation showing the same non-operational Akonadi and blocked KMail GUI (after installation of Sun Java, setting this as system standard), but I was not able recreate this. The virtual system is running stable all the time after this event, and that didn’t change after the current updates.
Maybe i’ll be going to try the updates on my prod system soon. Or better wait for the KDE:Applications update…
Just looking for it and it arrived in the repo. Thanks wolfi323!
Same procedure after update to Plasma 5.6.4 / KDE Frameworks 5.22.0 / KDE Applications 16.04.1 / QT 5.6.0.
Akonadi is working in the background (still getting new mail notifications), Akonadi-dependant application windows are grayed and blocked (but new contents are shown there), Details button still does nothing 
Interestingly i can find the malloc errors like
*** Error in `/usr/bin/akonadi_control': malloc(): memory corruption (fast): 0x00007fe28400f5d8 ***
in .xsession-errors again. Don’t know about the relevance of these errors, but such errors are not seen on the working systems (prod with previous releases and virtual test system with current versions).
What annoys me is the fact that we don’t find the root cause for this strange behaviour. Even if i start with a fresh install on my prod system, no one can guarantee that even the clean system will not break again. I’m not familiar enough with KDE development to investigate this further, and i’m not sure about what’s needed to proceed with problem investigation. Any other idea what we can do to nail that down?
Success - I don’t know why, but on my prod system Akonadi and all dependent applications are running without any issues - and that status has survived two reboots.
What happened: I wanted to change the way to mount /tmp on a separate partition. Before i used a symlink to a mounted partition (don’t ask me why i used that). Now /tmp is mounted in fstab directly with some additional mount options and with this change the tmp partition has been formatted and was blank. Every boot and KDE start was OK since that change.
So maybe the cleaning of /tmp resolved the issue.
Today morning, starting KDE session, Akonadi running in background, but system is complaining that Akonadi isn’t working correctly in KMail…
I closed the KDE session, wiped /tmp, reboot → OK
What’s going on here? I’ll continue to use the current versions to see how it works.
Another update: After several reboots it turns out that the problem is not resolved. Connection to Akonadi is operational only if /tmp is wiped before starting KDE. But after some time an Akonadi resource crashes (most of all one of the akonadi_imap_resources) with the malloc error. From that point everything is failing again - until the next /tmp wipe and reboot. Really strange and I can’t reproduce this behaviour in the nearly identical virtual system.
Does anyone has a clue how to move forward? I’m lost…
Well, two days ago an “infinite loop” has been fixed in akonadi:
http://quickgit.kde.org/?p=akonadi.git&a=commitdiff&h=1b78ff453153c243ece1e6165995ab1812fc4826
I have no idea whether your hangs are caused by such an infinite loop (would somehow sound like it), nor whether this commit fixes exactly your problem, but if you want to give it a try a package is available here:
http://download.opensuse.org/repositories/home:/wolfi323:/branches:/KDE:/Applications/
That your imap resources are crashing in the first place with such a malloc error would sound fishy too, though I have no idea how to investigate this further.
Maybe try to set the environment variable MALLOC_CHECK_ to 0 or 1 to see whether it helps, e.g. by such a line in ~/.profile:
export MALLOC_CHECK_=0
wolfi323,
first of all, thanks for your time and for providing the package and infos.
Well, two days ago an “infinite loop” has been fixed in akonadi:
I installed your akonadi-server, reboot (without wiping /tmp) -> malloc error in akonadi_control 
Wiped /tmp, reboot -> all fine at start
Then according to your suggestion I set
export MALLOC_CHECK_=0
Reboot without wiping… → no malloc error in .xsession-errors reported, but connection to akonadi is broken (akonadi is running in background)
Another reboot, this time with wiping /tmp → all fine at start
Same tests with identical results after setting
export MALLOC_CHECK_=1
I can reproduce the following two situations:
- Fully operational system if I wipe /tmp and reboot.
- Broken connection to Akonadi if /tmp wasn’t wiped. In some very, very rare cases the system is operational.
But after some time up and running, something goes wrong, leading to an unresponsive KMail (I suppose this is caused by lost connection to akonadi).
It’s a mystery to me: This problem seems to appear on openSUSE (Leap?) and some selected systems only, is not reproducible on a virtual test system, depends on /tmp status (empty or not) at start time and is unreliable.
In my opinion there are two options now:
- Going back to the Leap update versions.
- Perform a clean re-install of openSUSE Leap on the prod system with immediate update to the most current versions and hope that the issue will never reappear.
OK, investigate and find the root cause would be the best option, but i don’t know how to do that.
If I could get good infos about debugging in KDE, I might be able to use my old programming skills to do some useful investigations to provide helpful infos to the developers.
Well, as you say that wiping out /tmp helps, it may be a good idea to find out which files exactly in /tmp cause the problem.
Maybe next time when the problem occurs try to move them away one by one and see which one fixes it.
As to “debugging in KDE”, Akonadi is not a KDE “application”, it only builds on Qt.
In general it is possible to enable further debug output via kdebugdialog(5) (that’s KDE specific though) and kdebugsettings (that actually affects Qt’s “categorized logging”, but the app must support that of course).
I’m not sure how to best debug the problem in this case though.
Maybe ask on the kde-pim mailinglist?
https://mail.kde.org/mailman/listinfo/kde-pim
You should reach the KDEPIM/Akonadi developers there.
I’ve had no luck with the new update. I’ve tried clearing /tmp before rebooting and that doesn’t seem to help on my system. There is a slight difference since the latest update, though. When I first boot, the KOrganizer update demon shows up on my screen with Akonadi seeming to be up. KMail opens with the usual Akonadi problem. If I close KOrganizer and reopen it, it shows up with the Akonadi problem.
Could this be related to something Akonadi stores on shutdown? For the longest time, when I boot my computer KMail opens on my Plasma screen with two or three message composer windows and sometimes a blank draft of a message, this despite the fact that upon shutdown I had no drafts in the draft mailbox or any message composer windows open. It is possible that some time several months to a year ago, I might have shutdown or crashed with such windows open, but never since then. Is there a way to purge Akonadi’s memory of this? Perhaps that is related to the problem.
Just clutching at straws…
Akonadi doesn’t store anything at shutdown AFAIK.
For the longest time, when I boot my computer KMail opens on my Plasma screen with two or three message composer windows and sometimes a blank draft of a message, this despite the fact that upon shutdown I had no drafts in the draft mailbox or any message composer windows open. It is possible that some time several months to a year ago, I might have shutdown or crashed with such windows open, but never since then. Is there a way to purge Akonadi’s memory of this? Perhaps that is related to the problem.
That’s unrelated to Akonadi.
KMail itself remembers open message composer windows and restores them on start.
I think that’s stored in ~/.local/share/kmail2/, but I’m not sure at the moment.
I doubt it’s related to your problem though.
I can’t find where kmail stores the file you mentioned. It’s not in that folder. Having looked for it, I did find the following akonadiserver error message from the time of my last boot in the ~/.local/share/akonadiserver.error file. It looks like it might be more germane to the problem:
"Cannot connect to agent instance with identifier 'akonadi_akonotes_resource_0', error message: ''" "Cannot connect to agent instance with identifier 'akonadi_akonotes_resource_0', error message: ''"
Control process died, committing suicide!
"
0: akonadiserver() [0x5783d3]
1: akonadiserver() [0x5786b9]
2: /lib64/libc.so.6(+0x35120) [0x7f4ecfa7a120]
3: /usr/lib64/libKF5AkonadiCore.so.5(_ZN7Akonadi16AttributeFactoryD2Ev+0x54) [0x7f4eb2f8ea64]
4: /usr/lib64/libKF5AkonadiCore.so.5(+0x81ad9) [0x7f4eb2f8ead9]
5: /lib64/libc.so.6(+0x37b19) [0x7f4ecfa7cb19]
6: /lib64/libc.so.6(+0x37b65) [0x7f4ecfa7cb65]
7: /lib64/libc.so.6(__libc_start_main+0xfc) [0x7f4ecfa66b0c]
8: akonadiserver() [0x4209e7]
]
"
That said, I also seem to get some database errors of the following form later on, but they do not seem to crash akonadi:
Cannot pause an inactive timer
Cannot pause an inactive timer
DATABASE ERROR:
Error code: 1452
DB error: "Cannot add or update a child row: a foreign key constraint fails (`akonadi`.`collectionpimitemrelation`, CONSTRAINT `collectionpimitemrelation_ibfk_2` FOREIGN KEY (`PimItem_id`) REFERENCES `pimitemtable` (`id`) ON DELETE CASCADE ON UPDATE CASCADE)"
Error text: "Cannot add or update a child row: a foreign key constraint fails (`akonadi`.`collectionpimitemrelation`, CONSTRAINT `collectionpimitemrelation_ibfk_2` FOREIGN KEY (`PimItem_id`) REFERENCES `pimitemtable` (`id`) ON DELETE CASCADE ON UPDATE CASCADE) QMYSQL3: Unable to execute statement"
Query: "INSERT INTO CollectionPimItemRelation (Collection_id, PimItem_id) VALUES (:0, :1)"
Is there a way to repair the database without losing all my mail folders, calendars, etc.?
Well, it does save the text of open composer windows in there, in the autosave folder.
It might remember open windows somewhere else though, maybe in ~/.config/kmailrc.
Having looked for it, I did find the following akonadiserver error message from the time of my last boot in the ~/.local/share/akonadiserver.error file. It looks like it might be more germane to the problem:
"Cannot connect to agent instance with identifier 'akonadi_akonotes_resource_0', error message: ''" "Cannot connect to agent instance with identifier 'akonadi_akonotes_resource_0', error message: ''" Control process died, committing suicide! " 0: akonadiserver() [0x5783d3] 1: akonadiserver() [0x5786b9] 2: /lib64/libc.so.6(+0x35120) [0x7f4ecfa7a120] 3: /usr/lib64/libKF5AkonadiCore.so.5(_ZN7Akonadi16AttributeFactoryD2Ev+0x54) [0x7f4eb2f8ea64] 4: /usr/lib64/libKF5AkonadiCore.so.5(+0x81ad9) [0x7f4eb2f8ead9] 5: /lib64/libc.so.6(+0x37b19) [0x7f4ecfa7cb19] 6: /lib64/libc.so.6(+0x37b65) [0x7f4ecfa7cb65] 7: /lib64/libc.so.6(__libc_start_main+0xfc) [0x7f4ecfa66b0c] 8: akonadiserver() [0x4209e7] ] "
Well, apparently the akonadi_notes_resource_0 crashed. No idea if that’s related to your problem or not though.
If a resource hangs, it can block others too though, as I already mentioned some time back.
Have you tried to kill the akonadi resources processes one by one to see if killing a particular one makes akonadi responsive again, as I already suggested earlier?
If that helps, it would at least point to which particular resource gets stuck and blocks akonadi completely.
Is there a way to repair the database without losing all my mail folders, calendars, etc.?
You can just wipe out the database without loosing any data (or mail folders, calendars, etc.).
The database is just a cache, there is no data stored in there (unless syncing back to the real storage fails for some reason).
Although, some things (like the destination folders for filters) are referenced by the database id in the config files, so some things might have to be reconfigured afterwards.
The database is located in ~/.local/share/akonadi/, just remove (or better rename) the whole folder.
You probably should move ~/.config/akonadi/ out of the way too (I think that’s necessary that akonadi is working properly afterwards, but I’m not sure), the .dat files in there can cause problems (in the past at least) if they are corrupted (so maybe try to delete them as a first step, before you wipe out the database).
But didn’t you say you have the same problem on a fresh user account? (or maybe that was somebody else, this thread is quite long already…)
If that wasn’t you, it might be easier/better to just create a fresh user account and see if it works there.
PS: googling for your database errors lead me to https://bugs.kde.org/354536, but that should be fixed already.
It might be a good idea to run “akonadictl fsck” anyway (that should try to fix the database) and maybe even “akonadictl vacuum” (that should remove garbage from the database), but I’m not sure that will work if akonadi is not responsive in the first place.
Googling also found https://forum.kde.org/viewtopic.php?f=215&t=124898, which does suggest to delete the *.dat files in ~/.config/akonadi/.
And http://tsdgeos.blogspot.co.at/2016/03/workaround-for-trouble-with-updating.html suggests to run some SQL statements to fix the database.
Try this as well.