[Akonadi] [Bug 331486] New: creation of 1000s of 1byte files in inbox/new/ for "ghost" mails on start

Tue Feb 25 10:56:22 GMT 2014

https://bugs.kde.org/show_bug.cgi?id=331486

            Bug ID: 331486
           Summary: creation of 1000s of 1byte files in inbox/new/ for
                    "ghost" mails on start
    Classification: Unclassified
           Product: Akonadi
           Version: GIT (master)
          Platform: unspecified
                OS: Linux
            Status: UNCONFIRMED
          Severity: grave
          Priority: NOR
         Component: Maildir Resource
          Assignee: kdepim-bugs at kde.org
          Reporter: aseigo at kde.org

If I forget to quit kontact and akonadi before logging out, it happens from
time to time that akonadi apparently does not quit cleanly. Upon starting
kontact after logging in for the first time after reboot, akonadi then reports
anywhere from 5k-300k mails in the inbox that are unread.

Looking in .local/share/.local-mail.directory/inbox/new/ reveals that there are
that many empty files (1 byte in size, which at least makes deleting them easy
with `find`). Additionally, all unread emails that *actually* exist will be
duplicated anywhere from 3-5 times to as many as a several hundred times.

The only way I have found to get the system back into order is to:

* stop akonadi
* manually delete all the 1 byte files in the inbox
* start akonadi
* open akonadiconsole (kontact will not do here, for whatever reason) and
request a re-sync of the inbox folder

Sometimes I need to repeat the above a couple times, but eventually it notices
that there are, indeed, missing items. What I see as debug output, both on
startup and during re-sync:

Maildir::readEntry unable to find:  "1393320241.R898.freedom" 

There is one line generated for each email missing. I noticed that in
kdepim-runtime/resources/maildir/maildirresource.cpp readEntry is called in two
places without the return value being checked. It returns an empty QByteArray
on failure. Putting in suitable return statements at those two places does not
fix the issue, but then I start seeing this in addition to the above line:

ItemRetrieverException :  Unable to retrieve item from resource: <html>Invalid
item retrieved</html>

This seams to be repeated twice for each "unable to find" line.

Eventually, this stops and then a few of these lines will appear:

Error during executing query "UPDATE PimItemTable SET atime = :0 WHERE ( (
PimItemTable.id = :1 ) )" :  "Lock wait timeout exceeded; try restarting
transaction QMYSQL3: Unable to execute statement"
Unable to update item access time 
Error during executing query "UPDATE PimItemTable SET atime = :0 WHERE ( (
PimItemTable.id = :1 ) )" :  "Lock wait timeout exceeded; try restarting
transaction QMYSQL3: Unable to execute statement"
Unable to update item access time 
Error during executing query "UPDATE PimItemTable SET atime = :0 WHERE ( (
PimItemTable.id = :1 ) )" :  "Lock wait timeout exceeded; try restarting
transaction QMYSQL3: Unable to execute statement"
Unable to update item access time 

Eventually, akonadi continues and the mailfilter starts:

akonadi_mailfilter_agent(9522)/libkdepim Akonadi::PluginLoader::scan:
registering Desktop file
"/opt/kde4/share/apps/akonadi/plugins/serializer/akonadi_serializer_bookmark.desktop"
for ("application/x-xbel") @ ("legacy", "default", "KBookmark")

(several more similar lines appear ..)

And then we're back to not finding items, only this time we are told:

AkonadiAgentServer(9520)/libakonadi Akonadi::ResourceBase::itemRetrieved: Item
does not provide part "RFC822" 

Again, this appears to repeat once for every "ghost" email, and every so often
one these lines will appear:

akonadiconsole(9666)/libakonadi
Akonadi::EntityTreeModelPrivate::monitoredItemChanged: Got a stale notification
for an item which was already removed. 1047667 "1393320340.R525.freedom"

After some minutes of churning, local mail filters are applied at an extremely
slow pace and a huge amount of disk read/write activity between akonadi and the
mysql database ensues. Slowly but surely each of the valid, but now massively
duplicated, emails is filtered into their target folders as expected.

Depending on the amount of duplication, this can take anywhere from 10 minutes
to half an hour to complete, during which time I have no access to my mail.
This has been a persistent problem for the last 3-4 months of akonadi, updated
from the git master branch (akonadi, kdepimlibs, kdepim-runtime and kdepim)
every few weeks.

It is hard to put into words how disruptive this is to my daily workflow, and
has become a deal-breaker in terms of being able to use kontact.

Reproducible: Always

-- 
You are receiving this mail because:
You are the assignee for the bug.