Dovecot/Perdition IMAP session timeout
I have a Dovecot server that gets some old sessions. One back-end server has 5/224 sessions open since September and another 14 from this month that are more than 2 days old. A total of 8.5% of sessions are more than 2 days old. This isn't necessarily a problem on it's own, none of the servers have enough load that 8.5% more or less will matter. But it becomes a problem when a user accumulates enough open and possibly dead sessions over a month that the limit of open sessions is reached and they open a support ticket. It's documented that some MUAs have problems with sessions getting killed, the problems in question can't be that great because no Internet connection is 100% reliable and a significant portion of the user-base doesn't have persistent IP addresses. In my own testing the most I've been able to do is generate a warning message about a session being closed. Is there any reason for not killing the sessions? If there is no good reason not to kill them then is there a way of making Dovecot or Perdition kill a session after it's been IDLE for a couple of days? Otherwise I guess I'll have to use a cron job that kills them. -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/
On 17/10/2012 20:13, Russell Coker wrote:
If there is no good reason not to kill them then is there a way of making Dovecot or Perdition kill a session after it's been IDLE for a couple of days?
This, from the wiki, looks promising: imap_idle_notify_interval = 120 How many seconds to wait between "OK Still here" notifications when client is IDLEing. -- http://wiki.dovecot.org/MainConfig Given your context, I'd increase it from 120 to something like 1800, but should probably do the trick regardless. If the client has died, then after <n> seconds the activity will cause TCP to throw a hissy fit and zap the connection shortly afterwards.
On Thu, 18 Oct 2012, Jeremy Visser <jeremy@visser.name> wrote:
This, from the wiki, looks promising:
imap_idle_notify_interval = 120
How many seconds to wait between "OK Still here" notifications when client is IDLEing.
Thanks for the suggestion. nc localhost 143 a login user@example.com pass b select inbox c idle I did some web searches on that which suggested testing it. So I did the above to test it and in response got "* OK Still here" messages about every 2 minutes. So it seems that the default is 120 for that setting. This means that the old connections at least have a system with a working TCP connection assuming that Perdition and the remote end do the right thing when a TCP session ends. I expect that Perdition is operating well but it seems plausible that there are some firewalls and routers out there that mess up broken connections. -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/
participants (2)
-
Jeremy Visser -
Russell Coker