Topic: IMAP connection problems with Thunderbird and Outlook

[MJB]

We are experiencing some strange problems with IMAP connections to our company's SME Server machine. Most days everything works perfectly, but on days like today, we constantly have problems.

Here is the server configuration:

* Asus CUSL2 motherboard (Intel 815 chipset with on-board video)
* 733-MHz Pentium III
* 256MB of memory
* 40GB, 7200 RPM, IDE hard drive (85% free)
* Compaq Fast Ethernet 10/100 PCI network card (OEM Intel PRO100+)
* SME Server 6.0.1-01
* About 40 user accounts, maybe 10 active at any given time

Lately, we're experiencing timeouts or long delays accessing folders and e-mail messages on the server. For example, when I launch Thunderbird 1.0, it checks my inbox, reports no new mail, and finishes. However, when I click on a random folder (say, the Sent folder), I get this:

- Displays "Connected to 192.168.1.2..." on the status bar
- The blue progress bar on the status bar keeps cycling
- The activity spinner at top right keeps cycling, too

This can go on for several minutes, then stops. The contents of the folder are never displayed. When I send a message, I get this:

  Status: Connected to 192.168.1.2
Progress: The bar keeps cycling

Thunderbird doesn't display an error message, and it doesn't time out. The progress bar may keep cycling for several minutes with no sign of completion. A few people are using Microsoft Outlook XP, and they IMAP timeout error messages.

Rebooting the server sometimes clears the problems and sometimes doesn't; same thing for exiting and restarting the e-mail client. I've checked the imap/current log file, but I don't see any obvious indications of problems. I don't know where to go from here. Is anyone else seeing IMAP problems like these? Does anyone have ideas of things that I can check?

[mach1_4fun]

Hey MJB,

I have run into a similar problem..
I'd like to hear if anyone else has a similar problem and how they solved it.

Here's what I have under the hood:
I am running dual 600 MHZ p3's
and 2gigs of crucial RAM
on a HP netserver 2000
We are running around 200 email accounts at any given time. With probably between 20-40 simulatneously accessing it during the height of the day. I think I have one of the bigger email servers out there as far as contribs.org community goes.

There are a quite few culprits for this one: (in fact I haven't totally fixed the problem yet ...)

-IMAP is pretty RAM and processing power intensive. I would throw more RAM in there, like a 512MB stick or more.

-try running the "top" command over an ssh terminal when its all slowed down like you described, then you can know how much of your resources are eaten up. also try a "pstree" to see how many imap threads are going.

-from my understanding, the IMAP daemon used in 6.01-01 is a late beta release. If I had more programming experience with c and linux I would make a contrib. I would probably even pay to have someone build a contrib!!!

-Mine completely deadlocks when I have about 40 connections. I believe this has something to do with daemon tools controlling the various daemons.

-Try switching some of the users over to "pop" if at all possible. The ones at work that use it run into alot fewer problems and get all their email off of my server

-I have thought about adding a cron job to restart the imap daemon regularly to keep it going smoothly. Maybe it would help ?

Let me know if any of this helps,
anyone else have an input or other info on this issue?

[djhomeless]

Just curious,
Do you guys see delays when logging onto the box using ssh locally? I am and I discuss it here in this thread.

I also see delays with IMAP (regardless of client) whenever it first checks mail, or when it lists folders.

I have been given some advice to check the logs and ensure I have updated my ssh packages. However, I'm not sure where that leaves me with the IMAP issue.

Geoffrey

[mach1_4fun]

Hello,

I did update my ssh and ssl packages, but that was in September I think. I don't have a login delay via ssh unless its during the really busy hours at work (10-3).

I check the logs regularly, nothing out of the ordinary there. Just alot of logins.

The imap and pop daemons only allow a connection from 5 facilities (including the local one). We just pulled almost 2,500 emails today.

The other admin thinks that its time to get a beefier server seeing the number of accounts that we have. I am not so sure.

an interesting thing: I never see more than 20 imap threads running simulaneously. The first 20 are listed:
"-supervise---tcpserver---20*[stunnel---imap]"
after that the rest are listed as "-tcpserver---5[stunnel---imap]"
somewhere else on the tree.

I will copy the whole tree when we has a busy day.

if the imap service slows down, a restart of the daemon works great, for awhile.

[MJB]

Try switching some of the users over to "pop" if at all possible. The ones at work that use it run into alot fewer problems and get all their email off of my server

Converting people to POP3 accounts defeats the purpose of using IMAP: storing all of their e-mail on the server. This allows me to backup their messages in case the server dies (and protects their messages in case their PC's hard drive dies). It also makes their messages accessible from off-site via the web client.

I can't be sure without digging through the IMAP server's code, but I get the impression that it might have a memory leak or a problem with file handles.

[MJB]

-IMAP is pretty RAM and processing power intensive. I would throw more RAM in there, like a 512MB stick or more.

Well, my SME Server machine started having IMAP issues again today, so I increased the memory by 50% (from 256 megs to 384). This didn't fix the problem. Several hours have passed, and SME Server is still stalling/choking on files and folders.

I don't have time to beat my head on this wall. As a quick fix, I'm going to switch people from IMAP to POP3. As a permanent fix, I'm going to install a reliable e-mail system. Bynari Insight Server is high on the list.

[hanscees]

-IMAP is pretty RAM and processing power intensive. I would throw more RAM in there, like a 512MB stick or more.

Well, my SME Server machine started having IMAP issues again today, so I increased the memory by 50% (from 256 megs to 384). This didn't fix the problem. Several hours have passed, and SME Server is still stalling/choking on files and folders.

I don't have time to beat my head on this wall. As a quick fix, I'm going to switch people from IMAP to POP3. As a permanent fix, I'm going to install a reliable e-mail system. Bynari Insight Server is high on the list.

I would start to tcpdump sessions that do and do not go wrong and see what the difference is. Are there clients that do not have problems?

Try to analyse the problem no just scream. If it turns out to be hardware your bynari won't save you.

You might also use some analysis using "top" "ps waux", vmstat, iostat and so on.

Try the stats in the system manager for clues.


hc

[MJB]

I would start to tcpdump sessions that do and do not go wrong and see what the difference is. Are there clients that do not have problems?

No, the IMAP stalling/choking problems seem to happen to everyone, just at sporadic intervals. I haven't been able to find any pattern in their occurance.

Try to analyse the problem no just scream. If it turns out to be hardware your bynari won't save you.

I'm not screaming, merely stating a fact. SME Server is installed correctly, I'm not receiving any error messages (that I can find), and it is not working correctly. It is a very difficult to track down a problem when the software doesn't give you any hints as to what is wrong (especially when your users are constantly calling to say "The e-mail isn't working right!"). If I can't resolve this problem soon, I'll have no choice but to switch to a different platform. I'd rather not do this; other than the IMAP problem, SME Server has worked very well for us.

After digging through the forums, I discovered that Dovecot's IMAP capabilities weren't being reported to clients because it is fronted by imapfront <http://forums.contribs.org/index.php?topic=22699.0>. I installed Rick Jones' IMAP capability fix for Dovecot <http://www.activeservice.co.uk/sme/contribs/> in hopes that it would clear up the problem, but it hasn't (I've verified in the log files that this information is now being passed to the clients).

You might also use some analysis using "top" "ps waux", vmstat, iostat and so on.

Try the stats in the system manager for clues.

I am checking the server, but I don't see any obvious signs of problems.

[hanscees]

Hi,
I also had a very strange problem with dnscache, which turned out to be solvable. I was also yelling to start using bind again. But really, all software has its problems.

I resolved it by analysis and that is usually your only chance.

I would like to urge you to make a tcpdump of an email session that goes wrong, and one that goes ok.

so do
tcpdump -nlpi eth0 -s 0 -w /root/dumpbad host 192.168.3.4 and port 143
(ip of host 192.168.3.4 and also interface eth0 in this case )

and you will catch the session to file dumpbad. Do the same with a good session.
Then analyse the file in ethereal on your desktop with a good cup of coffee.

You can post the dump here or make it available or something. That will give people something to work with. It is not guaranteed to work, but it might give you clues.

There might be some imap  problem. If you find no differences apart from the speed you can conclude the problem is something else.

But you might find a lot of reconnects or other stuff.  So making a dump on all ports is also a good idea: to see what is going on on the network. Check the duplex settings of your server and switches and so on. SDo some ftp-tests to see if all is well with the network.
I have seen many problems with duplex settings: it only gives problems when the load on the network is high.


Next to that analysis try to do a resource analysis: make a ping script that logs continuously and see if you spot problems. Let someone watch top all day or do
"vmstat 5 > /root/vmstatfile" for an hour and see if it goes to idle 0 or something.

If nothing works you are out of luck, but you just might find something.

Also try to find out the imap version you have and search the web for bugs.

However, if I read the hardware you have and the number of users I would quess the harddisk might not hold up. 10 people loading files on a ide harddisk is a tough job.

also if you restart the daemon it works fine for a while suggests a resource problem.

You already changed ram right? I would stick in even more and a second disk that holds user-files or something. Or pop-boxes indeed: thgen files are not on that disk.

If that is the problem a server with raid 5 and scsi might be a real solution. But you want to make sure that is the problem first.





good luck

Hans-Cees

[hanscees]

hi, found some way to look at the disk io.

please have a look at man iostat

iostat -dk (-x device)
(d = only disk k=kilobytes)

you can do
iostat -dk 5

or for extended stats
iostat -dk 6 -x hda6
(hda6 is the / dir and holds /home with the maildirs.)

the await will tell you how long you are waiting for disk io. If this grows you might have a disk i/o problem.

for instance: iostat -dk 6
Device:            tps    kB_read/s    kB_wrtn/s    kB_read    kB_wrtn
dev3-0            0.33         0.00         3.33          0         20

tps is number of transfers per seocnd
kilobytes read/write per seconds.

you can see how fast your disk is with:

hdparm -Tt /dev/hda
or hda6

/dev/hda6:
 Timing buffer-cache reads:   128 MB in  2.12 seconds = 60.38 MB/sec
 Timing buffered disk reads:  64 MB in 16.26 seconds =  3.94 MB/sec



Ifd the stats show you use that up you have an io problem.

greetings

Hans-Cees

[MJB]

I posted a bug tracker report about my IMAP problems, and CharlieBrady suggested that it may be due to the connection limit on the IMAP service. A quick search of the forums turned up this fix:

/sbin/e-smith/config setprop imap ConcurrencyLimit 200
/etc/e-smith/events/actions/imap-conf
svc -t /service/imap

I made these changes to my SME Server config early this morning. Since then, I haven't had a single IMAP problem. I want to test this for a few more days before I declare that the problem is solved.

[loek]

That thing MJB suggests is most probably the cause.

I had the same problem a few months ago but only after searching these forums 10 times over again I finally ran into this old post which solved it for me:

http://forums.contribs.org/index.php?topic=20223.0

Set the number of max connections set to max no of users * 5 and IMAP seems to run smoothly.

Loek

[MJB]

CharlieBrady's advice did the trick. We have been running for 3 business days without any trouble from the server. Hopefully, this message thread will help other people with this problem, since the necessary IMAP settings don't appear to be well-documented (at least, I wasn't able to find them...).

[djhomeless]

Sadly this did not work for me, but considering I only have a few users on my box I suspected the number of conections wasn't the problem.

I am pretty certain my problem is a reverse DNS issue, but I have no idea how to go about solving it. Basically, regardless of the client, it takes exactly 30 seconds to retrieve my email and folders. This happens regardless if the account has a gig of mail, or only a few messages.

The reason I think this is a DNS issue is I used to have the same type of problem with logging onto the box with SSH. Once I typed in my password it would take 15-20 seconds to physicall log on. Adding an entry into the /etc/hosts file solved that problem. Sadly, it did nothing to improve the IMAP problem.

I've about given up on this.

Geoffrey