Created attachment 57611 [details] example of akonadi sync failure after reboot Version: unspecified (using KDE 4.6.0) OS: Linux I have four imap accounts set in akonadi and I get tons of emails each day on each mailbox, so I always suspect something is aloof when ... I don't get any email for an extended period. Each time this happens, I fire up akonadiconsole, and, lo and behold, while I am evidently connected to outside world, some or all of my imap resources "Failed to connect to server" (see attached screenshots). A simple "akonadictl restart" solves the problem, and 10 seconds later, my imap resources are syncing again. This problem usually happens when I resume from suspend or when I reboot. This might be related to the resources not being able to sync during the time it takes for my laptop to connect to my wifi network. So I have two comments, besides congratulating the PIM team for such a great job: 1) If this is a network problem at startup, akonadi should realise after 2 hours that my laptop is connected... 2) There should be a way to set up notifications when a resource is not syncing. I don't think my mom would have the idea firing up akonadiconsole after not receiving any email in a few days :-( For instance, the kmail tray icon could be crossed or something. That would be really helpful, as well as providing a "restart akonadi attached to it"... Besides that, everything works very well now, so thanks for the good work, dear devs! Reproducible: Sometimes Steps to Reproduce: reboot or resume from suspend to disk Actual Results: imap resources silently not syncing Expected Results: imap resources should sync at set intervals
Created attachment 57612 [details] example of akonadi sync failure after resume
This problem now happens even while my laptop is running, now. At some point, akonadiconsole shows every resource working fine, then, silently, two hours later NONE of them are connected. No other sign of error besides looking at akonadiconsole. This unreliability makes the kmail/akonadi system totally useless, unfortunately.
Just talking to myself, here. Apprently, the issue is that akonadi does not recover from losing the internet connection, such as when my wifi card goes south...
I can confirm this bug report. Whenever my computer suspends and wakes at another place (with another wifi connection), kmail doesn't show new emails (even after manually checking) even though all imap resources are in connected state.
ups, I just realised that that my bug is more like #249828 I'm not sure if it's a duplicate of this bug.
I too experience loss of IMAP connections after resume from standby. They actually show 'disconnected' or something like that in the Kmail Accounts/Receiving dailog. Clicking 'Modify...' and without actually touching anything closing the modify dialog (by pressing OK) is the quickest work-around I've found.
I can see that also on my up to date Fedora 16 (kde 4.7.3). This is a most annoying bug. The trick in comment #6 of clicking Modify and then Ok to restart synchronization is a life saver. Is there a magical command line invocation (based on dbus-send, typically) that would simulate the effect on clicking Modify and then Ok ? (In other words, how does kmail notify akonadi that the collection might have been changed ?) I would love to put that in NetworkManager resume scripts... By the way, isn't this bug and bug 258479 duplicates ? The comments in 258479 claim the problem should be fixed in 4.7.1, but this does not seem to be the case...
Created attachment 66312 [details] script to shake up akonadi resources after getting back online @Éric: here is the script I use to "shake up" akonadi after resume/suspend. It is set to act on IMAP resources, google data and google calendar resources, but you should be able to easily modify it to suit your needs.
Thanks a lot for the script; I now know of the existence of qdbus ! Some remarks: In my case, after some suspend/resume, my imap account is not synchronizing. In kmail, Ctrl-L does not do anything, even though the resource is marked as ready in the configuration dialog. With qdbus, the method org.freedesktop.Akonadi.Agent.Status.statusMessage returns "Prêt" (the french for "ready"), the method org.freedesktop.Akonadi.Agent.Status.isOnline returns "true" but it is not working and the method org.freedesktop.Akonadi.Resource.synchronize does not do anything. As such, the script in the attachment does not do anything. (By the way, I find it absurd to translate message strings in the ABI; it should be translated at the level of the GUI, not in the actual message. If a script expects "Ready" and gets "Prêt", it won't work. And why Oh why translate Ready and not translate true ?) However, If I run in turns the methods org.freedesktop.Akonadi.Agent.Control.reconfigure and org.freedesktop.Akonadi.Resource.synchronize then I get a synchronization and everything works nicely. I assume that kmail issues these methods when one clicks on "Ok" in the dialog box for modifying an account.
I experience a more general synchronization failure. I have my sent-mail folder on the IMAP resource. Kmail2 says the folder contains 2307 messages. But it doesn't display them all. It displays only about half of them. Looking with mutt on the imap-folder reveals that it misses 5 month of email. I assume the mysql table has been wrecked by something (I renamed a folder because of another issue). I assume I have to re-create the nepomuk/akonadi metadata. But how can I do that for a specific folder without destroying all the metadata. And why is akonadi synchronizing but kmail2 not displaying well? Looks like the optimizations got a bit too far and now it doesn't touch its index anymore.
I can confirm this still happens in KDE 4.8rc2.
I confirm this most annoying bug. openSUSE 12.1, KDE 4.7.2 P.S.: Salut Éric !
David fixed a lot of pb with imap connect/disconnect in 4.8 (after rc2) So needs to retest when 4.8 will release.
Am I wrong or has this been fixed in KDE 4.7.4? In my case, after Suspend to RAM everything seems to work fine now. openSUSE 12.1, KDE stable repository (KDE 4.7.4)
I also experience this problem, however, I have it even more annoying: I have a quite large IMAP mailbox with ~10 subfolders, each of them have >= 3000 mails. I use mail filtering which seems to slow down the synchronizing process additionally but even with filtering completely disabled the akonadi_imap_resource will inevitably display a pop-up-message saying "Connection lost" or "Connection timed out" after at most half an hour. From now on, the akonadi process hangs, cannot be restarted from the akonadi console and will never sync mails again. This happened before, but since my last Ubuntu update to KDE 4.9.4 it worsened: - Before, Kmail not syncing its IMAP accounts happened twice a week (or when waking up from sleep mode). Now it happens 5-6 times a day. I virtually get mails only every 2 hours, when I notice that the mail influx is too low for an average day and I kill the processs (well... when I think about it, this is actually not too bad :) Platform: Kubuntu 12.10 KDE: 4.9.4 KMail: 4.9.4
Created attachment 76671 [details] Output of kcmshell4 kcm_akonadi when executed on the command line and restarting IMAP resource
I, too, have to restart akonadi each time I wake up from sleep. KDE 4.9.5
*** This bug has been confirmed by popular vote. ***
same here with recent git
Created attachment 77522 [details] restart akonadi on new internet connection I got tired of wondering if akonadi was working properly after resume, so I wrote two scripts that restart akonadi when internet connection is restored (i.e. each time a wlan or eth interface is up). Alternatively, if you want to be less aggressive, in 50-restart_akonadi, you can use the script from comment 8 above (https://bugs.kde.org/show_bug.cgi?id=267483#c8) to only trigger a refresh of the resources...
This bug has only been reported for versions older than KDEPIM 4.14 (at most akonadi-1.3). Can anyone tell if this bug still present? If noone confirms this bug for a recent version of akonadi (part of KDE Applications 15.08 or later), it gets closed in about three months.
Just as announced in my last comment, I close this bug. If you encounter it again in a recent version (at least 5.0 aka 15.08), please open a new one unless it already exists. Thank you for all your input.