Version: 2.0 beta1 (using KDE 4.5.80) OS: Linux I have one of my IMAP resource that won't sync with the server, even when I ask for a manual sync. Even if I quit kmail several times. In account settings, the resource is said to be "connection established", and doesn't change state whatever I try to do. I've tried to set the resource offline on kmail shutdown, but no luck. Restarting akonadi using akonadi_control worked, the resource is now ready and syncing works. Reproducible: Sometimes Expected Results: The resource should not be stuck, somebody that does not know how to restart akonadi will not be able to unlock it.
I face similar problems here with both my IMAP accounts. On startup, if the network is not coming up fast enough, akonadi cancels refreshing the account and won't restart refreshing it if the connection is available again. Same happens after Suspend to Ram. The only thing that works, is opening the ressource, pressing there "Apply" and the already mentioned approach to restart akonadi at all.
Kevin, I'm trying since several days to gather more information why the imap resource doesn't synchronize the collection tree or why it is hanging there. Could you give me some pointers how to find out what's going on. There is no useful information in the akonadiconsole or in the debug messages by akonadi itself. You can also find me in #kde-devel as 'gladiac'.
This bug is still in 4.7.
A restart of akonadi or the akonadi_resource doesn't work. It is always hanging in the same state.
My error case is similar to Comment #4 from Andreas. With an Exchange 2005 server, when I first create the IMAP Receiving Account, Akonadi will retrieve all 283 messages in my account, and correctly identify 25 of them as new. I can view any email body in the message browser, and all 283 messages are viewable. Selecting a new message gives the following console message: posting retrieval request for item 24651 there are 1 queues and 0 items in mine request for item 24651 still pending - waiting processing retrieval request for item 24651 parts: ("RFC822") of resource: "akonadi_imap_resource_2" continuing request for item 24651 succeeded void Nepomuk::Query::QueryServiceClient::close() 246379 FLAGS (\Seen) void Nepomuk::Query::QueryServiceClient::close() akonadi_imap_resource_2(30740)/kdepimlibs (kimap) KIMAP::StoreJob::handleResponse: We asked for UID but the server didn't give it back, resultingFlags not stored. That looks "correct" to me. It pulls the body, then tells the server to mark the message "Seen" Pulling a message that's already been seen gives me this: posting retrieval request for item 24401 there are 1 queues and 0 items in mine request for item 24401 still pending - waiting processing retrieval request for item 24401 parts: ("RFC822") of resource: "akonadi_imap_resource_2" continuing request for item 24401 succeeded void Nepomuk::Query::QueryServiceClient::close() void Nepomuk::Query::QueryServiceClient::close() Next, I close Kmail (and do nothing with akonadi server in the background). I immediately re-open kmail, select the IMAP (Exchange server) Inbox, and see this in the console window: Database "akonadi" opened using driver "QMYSQL" posting retrieval request for item 24652 there are 1 queues and 0 items in mine request for item 24652 still pending - waiting processing retrieval request for item 24652 parts: ("HEAD", "ENVELOPE") of resource: "akonadi_imap_resource_2" continuing request for item 24652 "132612" failed: "Resource was unable to deliver item" ItemRetrieverException : Resource was unable to deliver item kmail2(30880)/libakonadi Akonadi::EntityTreeModelPrivate::fetchJobDone: Job error: "Unknown error. (Unable to fetch item from backend)" The spinning "I'm working on it" icon appears next to the "Inbox" entry of my Exchange Server IMAP folder, but nothing is shown in the message list window, and nothing comes up in the message read window. Even if I leave it alone for 6 or 8 hours, the icon continues to spin with nothing displayed. Basically, this means that I need to delete the old IMAP resource and create a new one every time I restart Kmail. Obviously, that's not a workable solution. I'm not sure how to mark this bug as "critical failure, makes program unusable," but that's how it affects me.
Same bug here with latest 4.7.0 rpms from OpenSUSE 11.4 (repositories/KDE/Release). A supplementary mention: the IMAP server seeming to refuse to answer completely is a rather old UW version (mbox format). The grave problem is that the blocking is such that even the other akonadi ressources become unuseable (my other servers get stuck for tens of minutes at a time). When removing the problematic server, all behavior returns to normal.
I have four IMAP resources and two of them stopped working correctly last week. Before that I've never had a problem since using kmail2 (the old kmail and IMAP was always problamatic for me). Now I can't even get the IMAP resources working after kmail restart, akonadi restart, computer restart... nothing works. The two IMAP resources stopped working at different times. The first stopped working last saturday when I first encountered a new (unrelated) bug (#281704). The other resources stopped working in the week after when I successfully reproduced the bug. The reason that the resources stopped working might therefore be--as descriped in the others bug's description--moving whole directories with several e-mails between IMAP resources. Up to now I have not yet tried to readd the broken IMAP resources.
OK, that report is actually going in several directions now depending on the comments. For the initial report up to comment #4 I think it is related either to 235835 or to 257722. Regarding #5, please retest on latest 4.7.x and check if it still applies in which case it'd need a separate report. It should be fixed by now though AFAIK. Regarding #6 that looks like another 235835. Regarding #7 that looks like another symptom of some of the database corruptions we've seen (likely from an upgrade of older unstable versions). If that still shows up on a clean database it would need a separate report. Because it got stretched in several direction I'll just close it as INVALID (although I think the individual issues were valid at different point in time, it just makes the overall report hard to use).
Well, I believe marking this as invalid is unfortunate. Comment #6 is dispatched as a case of 235835, which has no relation to the problem I expecience. With KMail from KDE-4.7.1 (KMail 4.7.1 "release 8"), I can <b>still</b> reproduce reliably the complete locking of akonadi when trying to connect to my main imap server (at workplace, an old UW server). It just sits there with "Connection established" next to the ressource and nothing else works (nor this neither other akonadi ressources). I use openSUSE rpms for OpenSUSE-11.4 (from their KDE/release/4.7 repository).
Then please open a separate report. And I will need more information to be able to do anything about it, namely: * the rought amount of mail * the exact IMAP mail server used (UW server doesn't ring any bell to me) * was there any network connectivity issue * is the database a fresh one, or it got through failed migration attempts Also to debug that kind of cases efficiently, I'd need to be provided with some idea of the IMAP traffic which created the issue. That can be done by setting the KIMAP_LOGFILE environment variable and restarting the akonadiserver. For instance: export KIMAP_LOGFILE=imaplog akonadictl restart Look at the pid of the imap resource you should then have a couple of imaplog.pid.* files. Wait for the crash, and then provide me what happened before the crash. It's the best way for me to create a test case that I can reproduce here. Only caveat though is that some private data is likely in the log (except the authentication phase, after that it logs everything) so you'd have to trust me with your data and send it privately.
OK. Thanks for your attention. Finally this discussion (and today's actions on this bug report) are concluding for me a rather bitter and long wait. I now know exactly what happens. The problem with that generic UW imapd (university of washington imap server, was once one of the most used in the category) is that by default it is programmed to give access to the whole user directory on a LISTDIR request. Changing this rather lame default would require modifying and recompiling the server code and this is not an option. I remembered finally (damn this makes me feel old...) that I always had problems with kmail and that each time that I reconfigured my user account, I needed to pay very careful and special attention to kmail wanting to suck all my (50G) user data from the imap server through access to my (workplace) home directory. The trick was to correctly set the "Namespaces" in the old kmail versions to point to the right directory in my home account on the server. Unfortunately the new kmail2 (well, akonadi...) doesn't offer this option anymore. Or at least I don't find it. There are for now two eventual workarounds: - serverside subscription before hitting for the first time the OK button on that (faulty) server configuration (this is possible but tedious and the final result is subpar) - local subscription, but this requires transferring all home directory data first and this is too heavy on the akonadi server (chicken and egg...). Then OK, this all makes my problem unrelated to this bug report. I will score through the bug reports see if I find something related. Thanks for listening.