'Stale' IMAP connections

[vlaurenz]

We've been having this problem for some time, and it's been very difficult to troubleshoot. Ocasionally IMAP connections for a given user will not die on their own, even after days. This problem then compounds itself until there are many, many stale IMAP connections for a given user. At which point, said user is no longer able to log in to Scalix via ANY client until some or all of the stale connections are killed. This stale connections can come from either SWA or an IMAP client.

Is anyone else seeing this? I've tried searching, but nothing seemed applicable.

Here's an example from this morning:

Code: Select all

352529   24276     1  0 Oct09 ?        00:00:28 in.imap41d -d
352529   23091 14394  0 Oct10 ?        00:00:00 in.imap41d -d
352529   25165 14394  0 Oct10 ?        00:00:00 in.imap41d -d
352529   15788 14394  0 Oct11 ?        00:00:00 in.imap41d -d
352529   27387 14394  0 Oct11 ?        00:00:00 in.imap41d -d
352529   31868 14394  0 Oct11 ?        00:00:00 in.imap41d -d
352529   11674 14394  0 Oct11 ?        00:00:00 in.imap41d -d
352529   23597 14394  0 Oct11 ?        00:00:00 in.imap41d -d
352529   28367 14394  0 Oct11 ?        00:00:00 in.imap41d -d
352529    8026 14394  0 Oct12 ?        00:00:00 in.imap41d -d
352529   21752 14394  0 Oct12 ?        00:00:00 in.imap41d -d
352529   26279 14394  0 Oct12 ?        00:00:00 in.imap41d -d
352529    5920 14394  0 Oct12 ?        00:00:00 in.imap41d -d
352529   18028 14394  0 Oct12 ?        00:00:00 in.imap41d -d
352529   22863 14394  0 Oct12 ?        00:00:00 in.imap41d -d
352529    2394 14394  0 Oct12 ?        00:00:00 in.imap41d -d
352529   13938 14394  0 Oct12 ?        00:00:00 in.imap41d -d
352529   31160 14394  0 Oct12 ?        00:00:00 in.imap41d -d
352529    8119 14394  0 Oct12 ?        00:00:00 in.imap41d -d
352529   17028 14394  0 Oct12 ?        00:00:00 in.imap41d -d
352529   21764 14394  0 Oct12 ?        00:00:00 in.imap41d -d
352529   31137 14394  0 Oct12 ?        00:00:00 in.imap41d -d
352529    7482 14394  0 Oct12 ?        00:00:00 in.imap41d -d
352529    9664 14394  0 Oct12 ?        00:00:00 in.imap41d -d
352529   15743 14394  0 Oct12 ?        00:00:00 in.imap41d -d
352529   22074 14394  0 Oct12 ?        00:00:00 in.imap41d -d
352529   25237 14394  0 Oct12 ?        00:00:00 in.imap41d -d
352529    1988 14394  0 Oct12 ?        00:00:00 in.imap41d -d
352529   10020 14394  0 Oct12 ?        00:00:00 in.imap41d -d
352529   13999 14394  0 Oct12 ?        00:00:00 in.imap41d -d
352529   23954 14394  0 Oct12 ?        00:00:00 in.imap41d -d
352529   32545 14394  0 Oct12 ?        00:00:00 in.imap41d -d
352529    3223 14394  0 Oct12 ?        00:00:00 in.imap41d -d
352529   10183 14394  0 Oct12 ?        00:00:00 in.imap41d -d
352529   17671 14394  0 Oct12 ?        00:00:00 in.imap41d -d
352529   20641 14394  0 Oct12 ?        00:00:00 in.imap41d -d
352529    1413 14394  0 Oct12 ?        00:00:00 in.imap41d -d
352529   12882 14394  0 Oct12 ?        00:00:00 in.imap41d -d
352529   17075 14394  0 Oct12 ?        00:00:00 in.imap41d -d
352529   28652 14394  0 Oct12 ?        00:00:00 in.imap41d -d
352529    7801 14394  0 Oct12 ?        00:00:00 in.imap41d -d
352529   12011 14394  0 Oct12 ?        00:00:00 in.imap41d -d
352529   23627 14394  0 Oct12 ?        00:00:00 in.imap41d -d
352529    2680 14394  0 Oct12 ?        00:00:00 in.imap41d -d
352529    6833 14394  0 Oct12 ?        00:00:00 in.imap41d -d
352529   18455 14394  0 Oct12 ?        00:00:00 in.imap41d -d
352529   30012 14394  0 Oct12 ?        00:00:00 in.imap41d -d
352529    1720 14394  0 Oct12 ?        00:00:00 in.imap41d -d
352529   13337 14394  0 Oct12 ?        00:00:00 in.imap41d -d
352529   24903 14394  0 Oct12 ?        00:00:00 in.imap41d -d
352529   29255 14394  0 Oct12 ?        00:00:00 in.imap41d -d
352529    8491 14394  0 Oct12 ?        00:00:00 in.imap41d -d
352529   20078 14394  0 Oct12 ?        00:00:00 in.imap41d -d
352529   24325 14394  0 Oct12 ?        00:00:00 in.imap41d -d
352529    3489 14394  0 Oct12 ?        00:00:00 in.imap41d -d
352529   15086 14394  0 Oct12 ?        00:00:00 in.imap41d -d
352529   19450 14394  0 Oct12 ?        00:00:00 in.imap41d -d
352529   31441 14394  0 Oct12 ?        00:00:00 in.imap41d -d
352529   10728 14394  0 Oct12 ?        00:00:00 in.imap41d -d
352529   15301 14394  0 Oct12 ?        00:00:00 in.imap41d -d
352529   27475 14394  0 Oct12 ?        00:00:00 in.imap41d -d
352529    6932 14394  0 Oct12 ?        00:00:00 in.imap41d -d
352529   12915 14394  0 Oct12 ?        00:00:00 in.imap41d -d
352529   25026 14394  0 Oct12 ?        00:00:00 in.imap41d -d
352529   25027 14394  0 Oct12 ?        00:00:00 in.imap41d -d
352529   25780 14394  0 Oct12 ?        00:00:00 in.imap41d -d
352529   25968 14394  0 Oct12 ?        00:00:00 in.imap41d -d
352529   30140 14394  0 Oct12 ?        00:00:00 in.imap41d -d


[ScalixSupport]

What client is this user using?

Does this user close his client ever?

Cheers,

Sascha.

[vlaurenz]

What client is this user using?

Does this user close his client ever?

Cheers,

Sascha.

SWA and Thunderbird. Yes, the user closes their mail clients regularly and this is not the first time we've seen this behaivior.

[thaecker]

I am experiencing the same problem, also with thunderbird and swa.
There have been approximately 30 imap processes 2 days after a reboot on a server with 3-4 clients and one user was not able to login.

Any suggestions yet?

[ivo_toshev]

I have this problem too.
I saw connection sitting there from more than a month !!!

[STXRich]

Scalix 11.2 on FC7
Seeing similar problems.

Imap sessions are left behind for certain users, particularly those checking email via phones.

Also noticed that when there are stale connections or even active ones, when scalix shuts down at night for it's backups, it is unable to close these connections. Causing it to hang for 300 seconds.

So far, the only way I've found to alleviate this is to to a

Code: Select all

killall in.imap41d

command prior to running

Code: Select all

omshut

Is there a better / cleaner way for scalix to take these processes out and clean them up?

I've also noticed that a fair amount of data seems to hang around in the imap-cache directories, cleaning them out daily seems be helping.

Thanks
-Keith-

[seanyseansean]

Scalix 11.2 on FC7
Seeing similar problems.

Imap sessions are left behind for certain users, particularly those checking email via phones.

Also noticed that when there are stale connections or even active ones, when scalix shuts down at night for it's backups, it is unable to close these connections. Causing it to hang for 300 seconds.

So far, the only way I've found to alleviate this is to to a

Code: Select all

killall in.imap41d

command prior to running

Code: Select all

omshut

Is there a better / cleaner way for scalix to take these processes out and clean them up?

I've also noticed that a fair amount of data seems to hang around in the imap-cache directories, cleaning them out daily seems be helping.

Thanks
-Keith-

Apologies for raising a thread from the dead, but we are having the same problem - we shut down scalix before generating an rsync backup, but it seems scalix isn't shutting down correctly.

Like Keith, if we kill the imap processes we can shut down okay. Is there a safe way of forcing a shutdown?

[mikevl]

Hi

Killing unix processes can be a bit of a trick. In your case the killall command is good but I would do this.

pkill imap
unfortunatly this also kills the imap server so
omoff -w -d0 imap && omon imap

if the processes still do not die i.e. they go zombie then you need to have a look at the parent processes and kill them, (luckily dosent happen all that often)

Defunct Processes
ps -ef --forest | less
or
ps -axjf |more
or
ps -ejH

will give you a tree with parent processes of any zombie processes

then a simple
kill -9 parent process will allow the zombies to die a natural death.

Mike