Summary: | gets stuck on one request that times out, kmail and akonadiconsole do not display any mail payloads anymore, stuck waiting | ||
---|---|---|---|
Product: | [Frameworks and Libraries] Akonadi | Reporter: | Martin Steigerwald <martin.steigerwald> |
Component: | libakonadi | Assignee: | kdepim bugs <kdepim-bugs> |
Status: | REOPENED --- | ||
Severity: | major | CC: | auxsvr, clearmartin, davidbryant, kdepim-bugs, Martin, OSidorkin, rasasi78, simonandric5, thiago.bauermann, vkrause, winter |
Priority: | NOR | ||
Version: | unspecified | ||
Target Milestone: | --- | ||
Platform: | openSUSE | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Sentry Crash Report: |
Description
Martin Steigerwald
2015-01-21 12:25:33 UTC
I put it on severity major, as basically this makes it impossible to use KMail for reading mail with Exchange IMAP and probably in other situations unless restarting either KMail and/or Akonadi several times a day. I think I need to restart Akonadi now, as it seems to me that Akonadi IMAP resource is stuck. I remember some other bug like this, but I didn´t find it with search terms "Exchange" or "unable to retrieve". Anyway, this at least contains quite some debug information. Now trying to restart kmail: And it helps. Now I can access mail again. Interesting. I bet what might work as a temporary work-around would be to kick IMAP resource somehow. A restart in Akonadiconsole doesn´t work. Now Akonadiconsole GUI is frozen completely after KMail restart. At, there goes. Too much debugging output in there. Freezes occassionally. So it seems to me that the one request to display a mail in KMail while Ext4-ml folder synchronizing stops at 97% seems to block IMAP resource completely, until I stop and restart KMail again. I want to add that I see the "Unable to retrieve item from resource: Did not receive a reply." with my private setup which primarily filters my main and my other POP3 accounts in a huge local maildir resource from time to time as well. Sometimes it helps to really quit KMail, make sure the process is really gone, and then restart. But I also had it that I have to restart Akonadi as well. I think I may look into this as well the next time it happens. That setup also has an 30-day limited Dovecot based IMAP account, so it may be a similar issue. If a KMail restart would help in all cases, I´d suspect that KMail and Akonadi loose connection to one another sometimes. But now I had it several times that I also had to restart Akonadi itself as just restarting kmail without making sure the process is really gone in between didn´t help to make KMail respond to user input again. With Akonadi 1.13 branch, kdepimlibs, kdepim-runtime and kdepim as of 12th of March this issue does not seem to happen anymore, neither for my private POP3 + IMAP setup, nor for the Exchange IMAP setup for work. There may still be some delays with blue waiting display in KMail, but usually after some seconds it gets back to work. I bet I can only set this to resolved/worksforme after setting it from unconfirmed to confirmed, so I try this. Nope, that doesn´t work, I cannot set it to resolved/worksforme, now I only have the option to set it back to unconfirmed. Ey, this is my bug. Anyway, feel free to set to resolved/worksforme. I reopen this. I have this again, for IMAP now, but rarely, and daily or even several times a day for POP3 to maildir resource. KMail and Akonadi just do not seem to talk to each other anymore, both idling, and KMail does not display any payloads or new mails in inbox mail list anymore until restarted. I did a clean install of openSuSE LEAP 15.0 about a month ago. This problem started soon thereafter. A bunch of spurious files are generated,and a bunch of mysql records that tie to remoteid=NULL are created. Then the whole thing locks up ... I see a "Please wait, retrieving message" screen in KMail that never goes away. So far, the only way I can fix it is by rebooting, or by stopping and restarting the Plasma desktop (log out, then log back in). I've tried poking around with akonadictl from a console window, but have had no luck with that approach so far. I haven't tried "killall" and "kstart" from Krunner ... I'll try that the next time this happens, and add another comment at that time. Dear David, thanks for adding your update to the bug report. However, if you change the version please also really set a new version, instead of setting 'unspecified'. Do 'akonadictl --version' and specify the version you see in the bug report. If the version is not in the selection, please select the closest one and put the output of the command in a comment. Please do not expect upstream developers to know or dig out what version OpenSUSE LEAP 15.0 would contain. Also preferably use OpenSUSE LEAP 15.1 to test with the newest version available. Additionally for me "akonadictl stop" and "akonadictl start" worked in order to bring Akonadi back into a working state. So your issue may even be something completely different. It would be beneficial to at least gather some console output to see whether you are really having the same issue. Especially whether you see the same: request for item 1669405 "902" failed: "Unable to retrieve item from resource: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken." kind of messages. For that to see start kmail from a terminal. Well, my version of PIM (Akonadi et al.) is 5.7.3, and that's not on the list, so that's why I said "unspecified" ... there wasn't any way to say "other" and fill in the blank, that I could see. My issue isn't at startup time. KMail just freezes up from time to time, apparently at random. I download all my e-mail using POP, so my set of folders is pretty big and elaborate -- about 20,000 files and 1.6GB, according to Dolphin. I've been using KMail since 2003. I don't have enough room to run more than one version of Linux on my current box. And it takes a lot of work to install a new release.So thanks for the suggestion about 15.1, but I'm not likely to undertake that endeavor right away. I have already tried stopping akonadi and restarting it. I don't think there are any issues with KMail when it first starts -- just a minute -- I'll go check. I do get a couple of warning messages. ------------------------------------------------------------------------- [0805/084258.513261:WARNING:stack_trace_posix.cc(648)] Failed to open file: /home/david/#2753352 (deleted) Error: No such file or directory 1 : "Uncaught ReferenceError: qt is not defined" 1 : "Uncaught ReferenceError: qt is not defined" -------------------------------------------------------------------------- The first one makes some sense to me ... after KMail froze up the last time, there were about 100 spurious objects ("no RID") and 75 spurious files ("unreferenced external files") when I ran "akonadictl fsck". Akonadi wouldn't get rid of all of them on its own, so I resorted to brute force (I got this trick from somebody named Karl (Langenfeldt?) in the openSuSE forums.) ~: find .local/share/akonadi/file_db_data/ -type f|xargs rm As I recall, that erased about 20 unreferenced external files. So the one file KMail is squawking about may be one of those. The other messages, about "qt", make no sense to me, at all. Thanks! PS I just opened this bug report because I haven't had this problem with KMail until very recently. It's not a real big deal as far as I'm concerned. It's just an annoyance -- when it stops working, I have to shut KMail down, than log out of Plasma and log back in again. That takes maybe 2 or 3 minutes. A nuisance, but not the end of the world. :) (In reply to Martin Steigerwald from comment #7) > Dear David, thanks for adding your update to the bug report. However, if you > change the version please also really set a new version, instead of setting > 'unspecified'. Do 'akonadictl --version' and specify the version you see in > the bug report. If the version is not in the selection, please select the > closest one and put the output of the command in a comment. Please do not > expect upstream developers to know or dig out what version OpenSUSE LEAP > 15.0 would contain. > > Also preferably use OpenSUSE LEAP 15.1 to test with the newest version > available. > > Additionally for me "akonadictl stop" and "akonadictl start" worked in order > to bring Akonadi back into a working state. So your issue may even be > something completely different. It would be beneficial to at least gather > some console output to see whether you are really having the same issue. > > Especially whether you see the same: > > request for item 1669405 "902" failed: "Unable to retrieve item from > resource: Did not receive a reply. Possible causes include: the remote > application did not send a reply, the message bus security policy blocked > the reply, the reply timeout expired, or the network connection was broken." > > kind of messages. For that to see start kmail from a terminal. David, Akonadi 5.7.3 is quite old, from KDEPIM 18.04 from April 2018 if I got this right. I am still not clear whether it is really the same bug, as I for me the original issue did not happen anymore since quite a while and I just forgot to close the bug report. Please consider to test with a newer KDEPIM/Akonadi version. You may use KDE Neon ISO images in a virtual machine for that. In any case I suggest you report your issue as a new bug, cause this bug IMHO is quite old, got quite convoluted and difficult for developers to make sense of. In that case I'd close this bug. Also if just replying to the last comment it is not necessary to quote and top-post. Short and precise is key for developers to act on bugs, which I did not adhere to back then either. |