Bug 332400

Summary: IMAP IDLE stops working after some time.
Product: [Frameworks and Libraries] Akonadi Reporter: Christian Mollekopf <mollekopf>
Component: IMAP resourceAssignee: Christian Mollekopf <chrigi_1>
Status: RESOLVED UNMAINTAINED    
Severity: normal CC: kdepim-bugs, mike, miso, rdieter, vkrause
Priority: NOR    
Version: unspecified   
Target Milestone: ---   
Platform: unspecified   
OS: Linux   
Latest Commit: Version Fixed In:
Sentry Crash Report:

Description Christian Mollekopf 2014-03-21 13:30:19 UTC
IDLE works for some time after starting up the resource, but then new events suddenly stop being delivered:

C: A000008 IDLE
S: + idling
S: * 3791 EXISTS
S: * 0 RECENT
S: * 3792 EXISTS
S: * 1 RECENT
S: * 3793 EXISTS
S: * 2 RECENT
S: * 3794 EXISTS
S: * 2 RECENT

Since it doesn't look like the connection is being dropped or anything alike this could be a server bug (I tried with cyrus).

Reproducible: Always
Comment 1 Christian Mollekopf 2014-03-21 13:32:08 UTC
also netstat shows two open tcp connections to the server, so it must be something else.
Comment 2 Christian Mollekopf 2014-03-21 13:56:36 UTC
And then somtime way later:

C: A000008 IDLE
S: + idling
S: * 3791 EXISTS
S: * 0 RECENT
S: * 3792 EXISTS
S: * 1 RECENT
S: * 3793 EXISTS
S: * 2 RECENT
S: * 3794 EXISTS
S: * 2 RECENT
S: * 3795 EXISTS
S: * 3 RECENT
S: * 3796 EXISTS
S: * 4 RECENT
S: * 3797 EXISTS
X


akonadi_imap_resource_0(28523) ImapIdleManager::onStatsReceived: IDLE stats received: KIMAP::IdleJob(0x1402f60) "INBOX" 3795 3
akonadi_imap_resource_0(28523) ImapIdleManager::onStatsReceived: Cached information: "/INBOX" 73 3794 2
akonadi_imap_resource_0(28523) ImapIdleManager::onStatsReceived: Resync needed for "INBOX" 73
akonadi_imap_resource_0(28523) ImapIdleManager::onStatsReceived: IDLE stats received: KIMAP::IdleJob(0x1402f60) "INBOX" 3796 4
akonadi_imap_resource_0(28523) ImapIdleManager::onStatsReceived: Cached information: "/INBOX" 73 3795 3
akonadi_imap_resource_0(28523) ImapIdleManager::onStatsReceived: Resync needed for "INBOX" 73
akonadi_imap_resource_0(28523)/kdepimlibs (kimap) KIMAP::SessionThread::doCloseSocket: close
akonadi_imap_resource_0(28523) ImapIdleManager::onIdleStopped: IDLE dropped maybe we should econnect?
akonadi_imap_resource_0(28523)/kdepimlibs (kimap) KIMAP::SessionPrivate::responseReceived: Received BYE:  "idle for too long "
akonadi_imap_resource_0(28523)/kdepimlibs (kimap) KIMAP::SessionPrivate::responseReceived: Received BYE:  "Fatal error: Lost connection to select
ed backend "
akonadi_imap_resource_0(28523)/kdepimlibs (kimap) KIMAP::SessionThread::doCloseSocket: close
akonadi_imap_resource_0(28523)/kdepimlibs (kimap) KIMAP::SessionThread::doCloseSocket: close
akonadi_imap_resource_0(28523)/kdepimlibs (kimap) KIMAP::SessionThread::doCloseSocket: close
akonadi_imap_resource_0(28523) ImapIdleManager::reconnect: attempting to reconnect IDLE session
akonadi_imap_resource_0(28523) ImapIdleManager::onSessionRequestDone: Starting IDLE connection
akonadi_imap_resource_0(28523)/kdepimlibs (kimap) KIMAP::LoginJob::LoginJob: KIMAP::LoginJob(0x18e94f0)
akonadi_imap_resource_0(28523)/kdepimlibs (kimap) KIMAP::SessionThread::reconnect: connectToHost "imap.mykolab.com" 143
Comment 3 Christian Mollekopf 2014-03-25 09:20:23 UTC
Unless KTcpSocket reads the data and hides it internally, the IDLE notifications simply never arrive at the client. I checked KTcpSocket's byteAvailable/stat/canReadLine as well as the sockets revc-q with netstat. We still get the "idle for too long" after 30mins, so the connection seems to be generally ok.

As we can see above, it seems as the server sends the "idle for too long", the pending notifications also get pushed through.
Comment 4 Michal Hlavac 2015-05-17 17:41:54 UTC
e.g. all routers from czech internet provider (UPC) are configured to drop every idle connection after 5 minutes and you can't change it. It will be good to have some option to set time inverval when akonadi reminds to server.
Comment 5 Mike Goodwin 2016-04-19 22:58:10 UTC
Is there any resolution to this? I'm seeing this on my kolab cyrus-imapd server as well. 

Seems to be server related as gmail still receives IDLE events
Comment 6 Denis Kurz 2016-09-24 20:34:34 UTC
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.
Comment 7 Denis Kurz 2017-01-07 21:33:04 UTC
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.
Comment 8 Mike Goodwin 2017-01-07 22:26:46 UTC
I still have this bug I just don't login to this bug tracker very often, and I worked around it so I stopped being annoyed by it. 

If you configure an IDLE account and disable "Interval mail checking" it basically stops working after it times out, and doesn't reconnect the IDLE session. 

Thus, I have interval mail checking set at about 20 minutes and that seems to mostly work ok.

However, My phone using K9 _always_ receives mail instantly via IDLE (because I can hear the alert) and it takes a substantial amount of time for Kmail to show the same notification on my computer (both of mine) 

I'm pretty sure most of the time It's just waiting the 20 minutes to check of I'm between checking intervals, so IDLE is probably doing nothing for me still.

I'd be willing to work with anyone but I'm not sure where else to progress the bug on my own. I clearly have a configuration and server that is prone to this issue, but again other clients like K9 work flawlessly.
Comment 9 Mike Goodwin 2017-01-07 22:30:43 UTC
By the way I'm on:

Plasma 5.8.5
kf5 5.29
kdepim 16.08

And will continue to be on the latest of what rdieter is doing with Fedora 25+