Bug 320180 - continuous network traffic generated
Summary: continuous network traffic generated
Status: RESOLVED DUPLICATE of bug 316840
Alias: None
Product: Akonadi
Classification: Frameworks and Libraries
Component: IMAP resource (show other bugs)
Version: 4.10
Platform: Other Linux
: NOR normal
Target Milestone: ---
Assignee: Kevin Ottens
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-05-23 16:26 UTC by miklos
Modified: 2013-06-14 19:43 UTC (History)
6 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
wireshark-kmail.png (362.62 KB, image/png)
2013-05-25 15:12 UTC, miklos
Details

Note You need to log in before you can comment on or make changes to this bug.
Description miklos 2013-05-23 16:26:47 UTC
After I start kmail, continuous network traffic is generated towards one of my imap servers. It's 14k up, 19k down. At first I thought it's for some kind of indexing, but that shouldn't last for several hours. It doesn't stop when kmail is closed, I have to kill the process manually.

 6924 ?        Sl    11:23  \_ /usr/bin/akonadi_imap_resource --identifier akonadi_imap_resource_1


Reproducible: Always
Comment 1 miklos 2013-05-25 15:12:29 UTC
Created attachment 80068 [details]
wireshark-kmail.png

I monitored it with Wireshark for a while. It seems that immediately after "client hello" the client closes the connection (FIN), and initiates a new connection. Then comes an "application data" from the server in the old connection for which the client answers with RST (stupid *and* rude). 

This goes on in an infinite loop until I kill the akonadi_imap process or I have kmail restart it in the settings dialog.
Comment 2 miklos 2013-05-25 15:34:31 UTC
Now I see that I forgot the best part of it: interval mail checking is not enabled, so it shouldn't even do anything in the first place. Especially if kmail is already closed.
Comment 3 Thomas Kear 2013-06-06 04:17:09 UTC
I've seen this issue on two different PCs in our office, running Kubuntu (4.10.2) and Gentoo (4.10.4) (both amd64 arch).  It appears it started around the time of upgrading to 4.10 for both.  It seems to have the same behaviour for both our local mail server (courier, with IDLE enabled) and gmail over imap.  Interval checking is enabled on both but looking the longevity of the IMAP connections I'd hazard a guess it's using IDLE on both rather than polling.

Peak connection count I've seen in the region of 35/second, which amongst other things caused our mail server, with a normal /var/log/maillog output of 35MB/week to write nearly 1GB in 4 days - each connection was causing one connect and one disconnect line in the log like the following:

Jun  6 15:58:57 mail imapd-ssl: Connection, ip=[10.0.11.101]
Jun  6 15:58:57 mail imapd-ssl: Disconnected, ip=[10.0.11.101], time=0, starttls=1

As the bug does not seem to present until kmail/kontact has been running for a half an hour to an hour, the most effective workaround I've discovered is to turn the connections offline briefly every 15 minutes with a cron job:

export DISPLAY=:0
qdbus org.kde.kontact /KMail org.kde.kmail.kmail.stopNetworkJobs
sleep 5
qdbus org.kde.kontact /KMail org.kde.kmail.kmail.resumeNetworkJobs

(replacing 'org.kde.kontact' with 'org.kde.kmail2' if you use kmail alone)

Occasionally it still goes haywire, to which 'akonadictl restart' appears to be the most effective solution.

There is not unusual logging anywhere I can find on the client when the above is happening, even in the console output from the restarted akonadiserver, at least some of which seems to end up on the terminal where you ran the restart command (and I assume is going into ~/.xsession-errors in a clean KDE session).
Comment 4 Ingo Stierand 2013-06-06 12:38:36 UTC
This seems to me to be related to bug #316840.
Comment 5 Thomas Kear 2013-06-07 09:14:22 UTC
(In reply to comment #4)
> This seems to me to be related to bug #316840.

I'm fairly confident bug 317790 is also describing the same issue, and possibly bug 315382 too.
Comment 6 Daniel Vrátil 2013-06-14 19:43:18 UTC

*** This bug has been marked as a duplicate of bug 316840 ***