On 09/19/2016 09:02 PM, ellie timoney via Cyrus-devel wrote:
I've been looking at tcp_keepalive a bit lately and I'm wondering how it
interacts with this?
It's my understanding that, in most cases, tcp_keepalive will do the job
of detecting clients that have dropped out, and allow us to close the
connection on our end. Since we're generally either waiting for a
command from the client, or producing and about to send output to the
client, this works -- because if tcp_keepalive detects that the client
isn't there, reads and writes to the socket will start failing.
But during the IDLE state, we only read from the client socket if select
reports it as having data ready for reading (presumably containing
"DONE"), and we only write to the client socket if there is activity on
the selected mailbox.
If the client's connection has dropped out, no data will ever appear on
the socket, so select will never flag it as readable, so we will never
try to read from it, so we will never receive the read error even though
tcp_keepalive detected the dropout. And if this client was idling with
a low-activity mailbox selected (such as Drafts or Sent), it might be a
very long time before any activity prompts us to write to the socket, so
we also don't receive the write error. And so even though the socket
itself knows there's no connection anymore thanks to tcp_keepalive, we
don't know that, because we haven't tried to interact with it. And so
the connection/process doesn't get cleaned up.
And so I think this patch is meant to provide an extra protection from
this case. tcp_keepalive is fine generally, but idling clients can slip
through the cracks in certain circumstances, so let's fill those cracks.
Does that sound right?
In writing this, I wonder what happens if a client initiates IDLE
without having first selected a mailbox. To my reading, RFC 2177
implies that this is sort of pointless, but doesn't make an explicit
statement about it one way or another. I don't know what Cyrus actually
does in this case -- there's something to investigate -- but I guess if
there's a crack there, the imapidletimeout patch will fill that too.
Any thoughts?
Cheers,
ellie
On Wed, Sep 14, 2016, at 05:11 PM, Thomas Jarosch wrote:
Hi Ellie,
On Monday, 12. September 2016 11:35:45 ellie timoney wrote:
[clock jumps]
Or does it? The man page says it's "not affected by discontinuous
jumps in the system time (e.g., if the system administrator manually
changes the clock)" -- great -- "but is affected by the incremental
adjustments performed by adjtime(3) and NTP". Which sounds to me like
NTP might still be an issue? (But: I have no real world experience of
this, I'm just reading man pages here.)
Good point. Not sure here, we didn't encounter an
issue for a long time. The event itself is rather rare these days.
Would it make sense to enable the timeout by default?
In the current version of the patch it's disabled (value 0).
I'm interested in hearing thoughts on this, particularly with regard to
what a reasonable default timeout might be. Though I like the "no
behaviour change unless you change configuration" aspect of defaulting
to 0.
We'll push out the three days default value next week.
I can report back in a month how good or bad the results are.
Cheers,
Thomas
Ellie, I agree a "crack" exists that idled processes may be slipping
through but so far I have little data to prove it.
Empirically I have one server with two clients (I have moved everyone
else to other servers to decrease the number of variables), and the
process count in the IDLED state for those two clients grows apparently
without bound (at least I haven't found an upper limit yet). I have
been increasing the point at which I am alerted for "excess imapd
processes" and it is up to 100 processes now. After about 24 hours
these two clients reach that point and every process in
/var/run/cyrus/proc/ is attributed to them like this.
imap hermione.ironicdesign.com [192.168.0.17] b...@cogift.co
cogift.co!user.b2b Idle
hermione is our nginx load balancer on an internal network.
As far as we have been able to tell, no other client has this problem.
Another data point...these are very low traffic accounts (6 emails for
one and 0 for the other in the last week).
I am going to contact the owner of these two accounts today and ask her
what client she is using and how often she has it set up to check email.
--
Andy Dorman
Ironic Design, Inc.
AnteSpam.com
