Version: unspecified (using KDE 4.5.80) OS: Linux I have added a IMAP resource for KMail 2 which is working fine. But after a system startup/resume from standby, the resource is not syncing. If I stop and restart Akonadi, the resource is syncing fine until next reboot/standby. I suspect this is due to the fact that my online resources (IMAP, WebDAV calendar and WebDAV contacts) are unavailable while Akonadi launches because it takes a moment for the the WLAN card to connect. One would assume that during next sync cycle, the online resource would by synced (at least for IMAP after 5min, which is the sync frequency) but this seems not to be the case. I verified this for IMAP and guess it is the case for WebDAV resources too. But for WebDAV I have not checked this thoroughly enough to be sure. So if I stop Akonadi (akonadictl stop) and restart it again (akonadictl start), it syncs instantly. Is Akonadi supposed to show this behaviour or did I ran into a bug? Reproducible: Always Steps to Reproduce: boot or resume from standby Actual Results: Akonadi does not sync Expected Results: Akonadi syncs
Upgraded to 4.5.85. Syncing after Suspend/Resume does work now. However, syncing directly after boot (when WLAN is disconnected during KDE startup) does not work. Akonadi Console tells for the according IMAP resource: "Could not connect to the IMAP-server xxxxxx.xxx. Failed to connect to server. This is obvious, but shouldn't Akonadi retry after the configured frequency time (on my system: 5min) has elapsed? It does not try to reconnect...
For me it does not work with .85. On the console I see: void Nepomuk::Query::QueryServiceClient::close() QObject::connect: Cannot queue arguments of type 'Solid::Networking::Status' (Make sure 'Solid::Networking::Status' is registered using qRegisterMetaType().)
Not sure if it helps but I have attached gdb to an imap resource that is stuck. (gdb) bt #0 0xffffe430 in __kernel_vsyscall () #1 0xb58b803e in poll () from /lib/libc.so.6 #2 0xb561e0bb in g_poll () from /lib/libglib-2.0.so.0 #3 0xb560dc46 in ?? () from /lib/libglib-2.0.so.0 #4 0xb560dfce in g_main_context_iteration () from /lib/libglib-2.0.so.0 #5 0xb73b0f7b in QEventDispatcherGlib::processEvents (this=0x80d5600, flags=...) at kernel/qeventdispatcher_glib.cpp:422 #6 0xb695d1da in QGuiEventDispatcherGlib::processEvents (this=0x80d5600, flags=...) at kernel/qguieventdispatcher_glib.cpp:204 #7 0xb7381a6d in QEventLoop::processEvents (this=0xbfff6724, flags=...) at kernel/qeventloop.cpp:149 #8 0xb7381c99 in QEventLoop::exec (this=0xbfff6724, flags=...) at kernel/qeventloop.cpp:201 #9 0xb7386740 in QCoreApplication::exec () at kernel/qcoreapplication.cpp:1008 #10 0xb68a43d4 in QApplication::exec () at kernel/qapplication.cpp:3736 #11 0xb75a9e2f in Akonadi::ResourceBase::init (r=0x817f570) at /usr/src/debug/kdepimlibs-4.6.3/akonadi/resourcebase.cpp:390 #12 0x08065b33 in init<ImapResource> (argc=Cannot access memory at address 0x5 ) at /usr/include/akonadi/resourcebase.h:188 #13 main (argc=Cannot access memory at address 0x5 ) at /usr/src/debug/kdepim-runtime-4.6.40.git.1304814363/resources/imap/imapresource.cpp:597
Still happens with .96
still happens with 4.7.0 sometimes, just restarting the resource in the akonadiconsole is sufficient.
I am also experiencing the issue with 4.7.0, for some reasons akonadi imap resource stops syncing if I experience a disconnection from. I would have to manually fetch my mails. everything however returns to normal and syncing works again once I restart akonadi.
I also still have this problem in 4.7.0. What really bugs me about it is that Kmail doens't say a word but just silently fails to load any new mails. if i just do a quick check i sometimes think i don't have any new mail when really akonadi just fails to sync.
@Bobby & Conrad. There was a bug pre 4.7.1 which caused akonadi not to be informed that the connection was back. It works for me now.
Yes, indeed should be gone since 4.7.1 if you have a setup with the libsolid networkmanagement layer working correctly. If your libsolid is somehow unable to report the network status properly, then what you're experiencing is bug 257722 which still needs to be fixed. Otherwise the suspend/resume case should work now.
*** Bug 273119 has been marked as a duplicate of this bug. ***
*** Bug 275698 has been marked as a duplicate of this bug. ***
*** Bug 247062 has been marked as a duplicate of this bug. ***
I am running 4.7.3 and I still see the problem. See my comments in bug 267483, which looks like a duplicate of this one.... (note that comment 6 of 267483 propose an interesting workaround.)