Date: Thu, 15 Nov 2007 15:10:59 -0700
From: David Boreham <david_list(a)boreham.org>
I doubt you need to use SO_KEEPALIVE. A couple of observations:
1. If you have ESTABLISHED state connections on one end that are not
in the same state on the peer, that would indicate something broken in the
network or the stack, rather than in the DS.
There's a lot of firewalls out there that silently drop idle connections,
rather than informing either side of the action (e.g., at least they should
send TCP RST packets but they do nothing). I think SO_KEEPALIVE is a
reasonable defensive measure to use, faced with such unfriendly behavior in
2. The DS already has connection timeout features that you can
Gordon Messmer wrote:
> > This morning I noticed that one of my directory servers has hundreds
> > of "ESTABLISHED" connections from a coworker's Linux host. The
> > directory server is running RHEL4, kernel 2.6.9-55.ELsmp, and
> > tcp_keepalive_time is set to 600. The client no longer shows an
> > ESTABLISHED connection on the port that is reported by netstat on the
> > directory server. It reports less than ten open connections.
> > I'm not sure whether or not an intermediary firewall is doing
> > something bad, but I expected that the directory server would use
> > setsockopt() to set SO_KEEPALIVE on its connections so that it could
> > detect connections that die off. After 600 seconds of inactivity, the
> > server should start sending probes, and then notify ns-slapd that the
> > connection is closed.
> > I'm not sure how I might filter keepalive packets with tcpdump, so I'm
> > not sure if I can verify that they're being used with that tool. Can
> > anyone identify the code that *should* be setting SO_KEEPALIVE on the
> > sockets, or otherwise speculate on why they might not be working?
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/