Version: kmail 1.9.6 (using KDE KDE 3.5.7) Installed from: Fedora RPMs I'm using kmail 1.9.6 on Fedora 7 (x86_64) configured to check 14 POP3 accounts. I'm intermittently receiving "Unknown host" errors when I attempt to check for mail on these servers. Since a number of the accounts reside on the same physical server, and say 5 connections are working and one isn't, then the host is definitely present and responding correctly. Rechecking the mail again against all accounts then works correctly 90% of the time. Checking for a third time seems to work 95%+ of the time without generating errors. Pinging the host proves that the server is indeed responding. I believe that this is unexpected behavior, and that when I click the "Check Mail In" button email should be received from all accounts. There is nothing in the remote mail server log (server is running courier) to indicate any failures. Connecting from other mail clients on this PC (Evolution for example) works as expected without generating any errors. Changing the connection preferences in kcontrol has no effect and the errors are still generated in kmail.
I've noticed upon checking the logs on the remote server that the connection from kmail isn't establishing a login for the affected account(s) when they're generating the errors in kmail. I see logins for the other accounts on that remote server, but not for the login that's intermittently failing.
Could this be related to: https://bugs.kde.org/show_bug.cgi?id=146314 ?
Well, I've got 20Mbit broadband here so the connection is unlikely to be congested enough to cause kmail to time-out. It is possible however that there is a concurrency issue that might be solved by restricting kmail to only connect to a maximum of n connections at once rather than attempting to connect to them all simultaneously. I did try setting a "pre command" of sleep 1, but that just got run right before all of the connections fired off - I was kind of hoping that I could set a pre-command for each account, but it seems that the all of the pre-commands are run right at the start of a manual "check mail in". Is that how that particular functionality was designed to work? Just as I write this I'm wondering if serially running the "check mail in" for a maximum of n concurrent multiple (when there are multiple) accounts might work better than connecting to all in parallel. Manually checking the 14 (in my case) POP3 accounts one-by-one would be less than ideal.
Dave, would it possible to just check if calling (manually for the test) one-by-one account helps in your case? Maybe it is not the issue with traffic but KMail itself.
Hi Maciej, yes I can confirm that manually calling each account one-by-one works without any problems in my case.
Dave, thank you for testing -- so it seems that sequential access to accounts is really needed instead of parallel. This would make this report a duplicate of the wish-report mentioned before.
Hi Maciej, are you using a 64-bit or 32-bit distro? Are you still using SuSE? I think that we might be able to rule out any distro-specific bits since I'm running Fedora 7 on an x86_64 and I think you're running on something different. It does seem that the two problems we've experienced could well have the same underlying cause relating to blocking or concurrency issues within kmail.
That's right -- we use different distros and CPUs (I use suse, 32bit CPU).
So different distros, different archs but we're experiencing similar problems. I wonder how we get the devs to take a look at this?
> I wonder how we get the devs to take a look at this? We already did that :-)
I don't see anyone other than you an me commenting on this... I was kind of expecting that a dev might ask for some trace information or something like that, although if they know what the root cause and fix is then maybe they don't need any additional info.
Try to add the following to your kmailrc (in .kde/share/config) : [Network] MaxConnectionsPerHost=1
I've modified my kmailrc as you identified above. I'll post back in a day or two after I've confirmed what effect the change has had. Initially things look more stable, but as with most of these types of problem it'll need a few days of use to confirm that this fix cures the issue.
I can confirm that modifying my kmailrc as outlined in comment #12 has resolved my issue. I'm going to mark this bug as resolved since my specific issue has been solved (many thanks Thomas).
*** Bug 166366 has been marked as a duplicate of this bug. ***
The solution mentioned in comment #12 didn't resolve the problem for me...
> The solution mentioned in comment #12 didn't resolve the problem for me... OK, reopening. You don't have DNS problems (i.e. websites taking a long time to show up in Konqueror), do you?
Thanks for reopening. Well I always used Firefox so I didn't notice it but indeed I think I do have these problems: websites start loading but Konqueror stops after the first few objects (images). After a long break in which I only see a white page the site gets rendered without all the elements that haven't been loaded so far. Sorry for not mentioning this but as I said I didn't use Konqueror. How can I get rid of this?
> Thanks for reopening. Well I always used Firefox so I didn't notice it but indeed I think I do have these problems: websites start loading but Konqueror stops after the first few objects (images). After a long break in which I only see a white page the site gets rendered without all the elements that haven't been loaded so far. OK, closing this bug again, your problem is bug 162600. As I mentioned there, a workaround is to change the DNS resolving of your system to bypass your router's DNS and go directly to the DNS servers of your ISP.