Akonadi server won't start
Martin Steigerwald
martin at lichtvoll.de
Thu Aug 19 09:11:40 BST 2021
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
More information about the kdepim-users
mailing list