Re: Akonadi server won't start

Hi David.

David Jarvie - 19.08.21, 01:35:05 CEST:
> On Tuesday, 17 August 2021 20:26:00 BST Ingo Klöcker wrote:
> > WARNING: Switching the database will make Akonadi forget more or
> > less
> > everything. Make a backup before proceeding. If you have lots of
> > filters configured, then export them before the switch. If you have
> > mail stored in local folders, i.e. if you are not using IMAP
> > exclusively, then you might also want to export those folders.
> > Akonadi may not have written all local mail to local files so that
> > some of those mails may only be stored in the database.
> 
> I've already encountered the issue which you describe, i.e. that after
> moving mails from IMAP into local folders, no file is created in the
> directory for that folder. I've tried copying instead of moving, but
> that doesn't work either (unlike in older KDE PIM software).
> 
> Is there any way of forcing mails in the Akonadi database to be
> written to local folder disk directories? It really isn't
> satisfactory for them to only exist in the database.

I am not aware of any such way. It has been topic here, in bug reports 
and I think also on kde-pim mailing list before.

On top of that for items that Akonadi failed to write to the remote 
storage, be it IMAP or a local maildir folder, remote is anything that 
is not the Akonadi cache, Akonadi will not attempt to write them at a 
later time. You see those with "akonadictl fsck". See those

Item "1744643" in collection "205" has no RID.
Item "1744697" in collection "205" has no RID.
Item "1744696" in collection "205" has no RID.
Item "1744764" in collection "205" has no RID.
Item "1744770" in collection "205" has no RID.
Item "1744836" in collection "205" has no RID.
Item "1744866" in collection "205" has no RID.
Item "1764092" in collection "205" has no RID.
Item "2123315" in collection "205" has no RID.
Item "2123303" in collection "205" has no RID.

messages.

Usually after a short while I had quite some of these in every Akonadi 
setups I have. Even those that except some very low volume IMAP accounts 
(a few mails a month if at all) have only local maildir storage. So far 
I have never got why Akonadi could fail to write out a mail file to local 
storage unless there would be an issue with the filesystem like it being 
100% full. Maybe it also happens if you stop or restart Akonadi at the 
wrong time, but I never really understood this. Maybe in case you stop 
it during a long running background operation. Still Akonadi is only 
able to do one operation at a time. So an folder indexing operation can 
block out KMail for a longer time. Often enough I stopped KMail and then 
Akonadi with "akonadictl stop" cause I wanted to be able to continue my 
mail work.

Thing is Akonadi is conceptionally a cache, however it extends that 
concept also to being a write cache. That means, before writing out an 
item it goes through the Akonadi cache. That means there is the chance 
that there is something in the cache that is not stored elsewhere so 
far. Idea is to be able to deal with IMAP servers that are unreachable 
at times. However for that Akonadi would need to retry storing the 
changes onto the IMAP server at a later time, yet this is not 
implemented.

Evolution on the other hand does not close the mail composer window 
until it made sure that the mail is stored on IMAP or EWS account. But 
it also displays a message when you try to close it during background 
operations. KMail does not need to wait for that as Akonadi operates in 
the background.

So Akonadi theoretically is more advanced, but in my point of view it is 
unfinished. And maybe a bit too complex and thus error prone. And I still 
claim it does a lot of needless work, likely re-scanning an IMAP folder 
after every 5 mails you delete.

It would be good at some point to actually tackle those shortcomings. 	
Daniel Vrátil did some work at this level, but he kind of burned out it 
seems before finishing his "make indexing great again" work that would at 
least avoid moving every mail through the cache for indexing.

I do not understand enough of Akonadi to actually address these 
shortcomings. And that probably part of the challenge here: Finding 
someone who is able to, willing to and has enough time to do the ground 
work that is needed to finally stabilize Akonadi to a point where it is 
rock solid and snappy at all times or replace it with something 
different. Plus there should not be a need for "akonadictl fsck". No 
other mail application I know needs this. Evolution does not, 
Thunderbird does not, mutt does not, notmuchmail does not. Or if it 
can't be avoided, it should be able to at least attempt to write those 
items without RID to remote storage again, but currently it just tells 
the other about the inconsistency between cache and remote storage 
without doing anything about it.

That is at least how much I understood.

I still stick with KMail cause it is a really good application. However 
I wondered to switch to Evolution often enough. I use it at work cause 
Akonadi with EWS is just not working reliable enough for me.

Best,
-- 
Martin