akonadictl fsck: What messages indicate real issues and what to do about them?

[Daniel Vrátil]

On Saturday, May 6, 2017 12:18:00 PM CEST Martin Steigerwald wrote:
> Hello.
> 
> After Akonadi was still occupied with stuffing all the 67000+ mails of the
> maildir folder I just moved inside KMail between different parent folders of
> the same and only maildir resource, I did a akonadictl stop to stop that
> madness. On next start of Akonadi it luckily forgot what it was about to
> do. I used akonadictl fsck to clean out the mess in file_db_data + db_data
> and that it did.
> 
> However even now it still reports some other issues I am not sure about. So
> I ask here: What messages indicicate real issues and what can I do about
> them?
> 
> I am first asking here, but I am willing to provide bug reports for any real
> issues. I store a copy of this fsck run. I don´t provide it in full here
> due to privacy concerns.
> 
> # Collections without RID
> 
> > Looking for dirty objects...
> > Collection "Search" (id: 1) has no RID.
> > Collection "OpenInvitations" (id: 395) has no RID.
> > Collection "DeclinedInvitations" (id: 396) has no RID.
> > Found 3 collections without RID. 
> 
> I think at least for "Search" this is expected. I am not sure about the
> other two, but it may be expected for them as well.

The OpenInvitations and DeclinedInvitations collections are virtual search 
Collections too, so they don't have RID.

We should probably not warn about those....

> # Items without RID
> 
> > Item "1289323" has no RID.
> > Item "1289324" has no RID.
> > Item "1289325" has no RID.
> > Item "1289326" has no RID.
> > Item "1289327" has no RID.
> > [… more than 1800 more …] 
> 
> RID is Remote ID as far as I understood. Yet the remote here is the local
> maildir. So these appear to be items in the database or file_db_data that
> are not inside the maildir. How can I look up these items and check whether
> this is an issue?

Yes, those are items that have not been succesfully replayed into maildir and 
only exist in Akonadi.

Run

SELECT id, storage, data FROM PartTable WHERE pimitemId = 1289323 AND 
parttypeid = (SELECT id FROM parttypetable WHERE ns='PLD' AND name='RFC822')

In Akonadi Console -> DB Console

If storage is 0, then the content of they email will be in the "data" field, 
otherwise the "data" field refers to a file in ~/.local/share/akonadi/db_data/
XY/ (where "XY" are the last two digits of the part ID).

> 
> # Items with RID that are dirty
> 
> > Item "1335889" has RID and is dirty.
> > Item "1349287" has RID and is dirty.
> > Item "1349736" has RID and is dirty.
> > Item "1360764" has RID and is dirty.
> > Item "1360766" has RID and is dirty.
> > [… easily more than 2000 …] 
> 
> What about these?

Those are Items that exist in maildir, were somehow changed (marked as read, 
moved, etc.) but the change wasn't succesfully stored in maildir. Currently 
there's no mechanism to force replay the change.

> # RID duplicates not matching the content mime-type of the parent collection

Means that you have a Collection that contains Items of a wrong time (e.g. 
emails in a calendar collection). Zero clue how that would've happened.

> What?
> 
> > Looking for rid-duplicates not matching the content mime-type of the
> > parent
> > collection
> 
> Some examples:
> > Checking akonadi_icaldir_resource_0
> > Found duplicates
> > 040000008200E00074C5B7101A82E00800000000201B33D46D12D201000000000000000010
> > 0
> > 0000085F61ED021447341AA2A15976A6B8FA7 
> > 
> > Checking aros-dev-ml
> > Found duplicates 1429563277.R787.merkaba
> > Found duplicates 1432116953.R995.merkaba
> > Found duplicates 1436178221.R34.merkaba 
> > 
> > Checking oss-security-ml
> > Found duplicates 1424451476.R127.merkaba
> > Found duplicates 1424451476.R255.merkaba
> > Found duplicates 1424453279.R126.merkaba
> > […]
> 
> Lots more.

The same email is stored multiple times in Akonadi in the same Collection. 
This can break sync and causes the "multiple merge candidates" issue.

> Seriously, I am not even sure I want to understand what this is about. But
> well… what is it about?
> 
> I think its good for fsck to provide more helpful messages:
> 
> 1. If its no issue, then don´t report it unless "-v" is given.
> 
> 2. If its an issue, advice what to do about it.

fsck corrects some of the issues itself, for some of them we don't have any fix 
as of now (like Items without RID or dirty Items)

> 
> Thanks,


-- 
Daniel Vrátil
www.dvratil.cz | dvratil at kde.org
IRC: dvratil on Freenode (#kde, #kontact, #akonadi, #fedora-kde)

GPG Key: 0x4D69557AECB13683
Fingerprint: 0ABD FA55 A4E6 BEA9 9A83 EA97 4D69 557A ECB1 3683
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kdepim-users/attachments/20170509/824cc5c4/attachment.sig>