| Summary: | akonadi_imap_resource hangs while syncing Inbox | ||
|---|---|---|---|
| Product: | [Frameworks and Libraries] Akonadi | Reporter: | Antonis Kanouras <antonis+kdebugs> |
| Component: | server | Assignee: | kdepim bugs <kdepim-bugs> |
| Status: | RESOLVED WORKSFORME | ||
| Severity: | normal | CC: | antonis+kdebugs, dvratil, foss, kdepim-bugs, lindsay.mathieson, Lukasz.Kurylo, m.seifert, rafaelalcantaraperez, vkrause |
| Priority: | NOR | Keywords: | triaged |
| Version: | 4.7 | ||
| Target Milestone: | --- | ||
| Platform: | openSUSE | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
Some additional info: I started Akonadi using "akonadictl start" and got this message right when it hanged on the terminal: Error during adding a record to table "PimItemFlagRelation" "Duplicate entry '1987-7' for key 'PRIMARY' QMYSQL3: Unable to execute statement" 1126 X-AKAPPEND 166 14211 (\MimeType[message/rfc822] "\\RemoteId[1]" \SEEN) ("PLD:HEAD[1]":2261,"PLD:ENVELOPE[1]":333,"PLD:RFC822[1]":13967) {16561}
+ Ready for literal data (expecting 16561 bytes)
1126 NO Unable to append item flags.
fixed by: delete from pinitemflagrelation; and adding imap account again Indeed, at the time I had tried to delete the duplicate entries from that table (had to restart the agent many times to find all of them) until I got scared of stealthy corruption in the future and wiped the database clean. This was probably caused by the fact that the database was created by pre-4.7 Akonadi and the KMail2's account migration wizard had run once (making a complete trainwreck). After that, all attempts to recreate IMAP accounts on that database failed like this. I think KDE PIM devs should just state that KMail -> KMail2 upgrades are not supported and be done with it; this bug will bite a whole lot of people when Ubuntu 11.10 is released with KMail2 and we'll have yet another "ALSA/Pulseaudio/Nepomuk sucks" saga. OK, so one more of the unrecoverable database corruptions. Volker is looking into them ATM, reassigning on the server. I'm getting this error with a GMail account. Have tried deleting the and re adding the account and deleting the whole Db - makes no difference, same error and can't see any emails. Thankfully I have the gmail web interface so I can actually use my email. KDE 4.8 RC1 I too encounter such 'hangs' again and again, not only on INBOX, but most often on that folder. Removing the resource and adding it again did not solve the problem. I hesitate to wipe the whole database, since I have quite a lot of resources... Akonadi has been upgraded a few times inbetween, no change. Currently running stable opensuse-KDE-4.10 packages. On thing I notice: when using 'aknadiresource' I can temporarily fix this issue (reanimate for the time being) by chosing 'Toggle Online/Offline' whilst the resource hangs. Currently I have to do this _two_ times: after the first times the display changes, another folder is said to be synced but things still hang. Note that the resource is still marked as 'online', although I clicked to switch to offline. After the second click the display changes again: still online, but now it simply says 'Ready' and then starts to sync fine after maybe 2-3 seconds. I have the impression that 2 or 3 agents are running in parallel, both being somehow blocked?!? I am happy to provide any information required. I installed a completely new system over the last days, openSUSE-12.3. I am now running KDE_4.10 form the openSUSE repo KDE:Release.410 and did NOT restore any data whatsover from a previous system. Instead I configured my PIM ressources from scratch. As a result I have a fully functional system (as expected), BUT: the issue I described above on 2013-02-09 exists with exactly the same symptoms: all works fine for some time, but sooner or later an imap resource with suddenly hang (no error) and stay locked, no matter how long you wait (well, I waited 2 hours...). Only when I restart akonadi or use the procedure sketched above: toggling the ressource to offline _twice_ I can get it to sync again. Then it works fine, until the next hang. I checked on server side and failed to see any suspicious message in the imap servers logs. Can you still reproduce this problem with KDE 4.12? I suspect this could be a problem in IMAP resource, but there were many changes in 4.11/4.12 cycle that might have fixed this odd behavior. @dvratil, in case you're referring to me, I haven't encountered this specific issue since I nuked the database, as I'd said in comment 4. I feel it was caused during the migration from KMail 1 to 2. I'm running KDE 4.12 atm, but haven't had any issues with Akonadi specifically since at least KDE 4.9. Slightly offtopic, but: Thank you for the great work you guys have put in to make Akonadi rock solid. I've been using the same database since 4.10 and it is still working flawlessly, despite heavy daily usage, power failures, many out of memory/disk space incidents and even crashes (hardware related). Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days, the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please set the bug status as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone! Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging Thank you for helping us make KDE software even better for everyone! |
Version: 4.7 (using Devel) OS: Linux Hello, I'm using Akonadi 1.5.80 on KDE 4.6.80 (4.7 Beta1) installed from the KDE:Unstable:SC OBS repo on openSUSE 11.4. After creating a new Akonadi IMAP resource, syncing with the IMAP server hangs with the resource displaying "Syncing Collection 'Junk' (3%)". The last few lines displayed in Akonadi Console are: -------------------------------------------------------------------------------------------- akonadi_imap_resource_3 (0x948630) 243 BEGIN akonadi_imap_resource_3 (0x948630) 243 OK Begin completed akonadi_imap_resource_3 (0x948630) 244 X-AKAPPEND 151 250334 (\MimeType[message/rfc822] "\\RemoteId[2272]" $ATTACHMENT \SEEN) ("PLD:HEAD[1]":2092,"PLD:ENVELOPE[1]":261,"PLD:RFC822[1]":247102) {249455} akonadi_imap_resource_3 (0x948630) + Ready for literal data (expecting 249455 bytes) akonadi_imap_resource_3 (0x948630) 244 NO Unable to append item flags. -------------------------------------------------------------------------------------------- Trying to force an "AbortActivity" or "RestartAgent" through the Akonadi Console does nothing. Only killing the imap resource or restarting the Akonadi server helps, and that only till it hangs again on some folder. The IMAP server used is Dovecot 1.2.15-4 as packaged with Debian Squeeze. Namespaces are enabled on the IMAP server, with "|" as the folder separator. After talking with Till on #akonadi, he suggested I make an account available for testing on the server, here are the details: Server: mail.metadosis.gr Username: akonaditest01@metadosis.gr Password: for-till Thanks, Antonio Reproducible: Sometimes Steps to Reproduce: 1. Create a new IMAP account (disconnected or not) through either Kmail or the Akonadi Console. 2. Try to sync. Actual Results: Syncing hangs on some folder most of the times, with no visible error in Kmail. Expected Results: I expected it to successfully sync all folders. The whole IMAP folder list is visible in Akonadi, and scattered messages in various folders (the ones it managed to download on each attempt before hanging).