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@kde.org Reporter: ase...@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. _______________________________________________ Kdepim-bugs mailing list Kdepim-bugs@kde.org https://mail.kde.org/mailman/listinfo/kdepim-bugs