you may have a (software/hadrware) firewall or switch/load balancer issue between ldap server and other servers. Some firewalls and switches don't let the RSET packets pass correctly. I've seen such a thing once between a database server and the web server. It was a hardware firewall (and switch) problem.
If it's not a frewall/switch problem you should also reduce nsslapd-idletimeout of cn=config
A part of our sysctl.conf file on 389 server is very similar to yours, so the problem is not in the kernel config:
# The total session drop time will be (net.ipv4.tcp_keepalive_time + net.ipv4.tcp_keepalive_probes*net.ipv4.tcp_keepalive_intvl)
# Time of session inactivity when the kernel will start to send probe packets
net.ipv4.tcp_keepalive_time = 1200
# How long the kernel waits in between probes
net.ipv4.tcp_keepalive_intvl = 30
We have three 389DS v1.2.6 on x86_64 servers, each one having ~100 parallel sessions, ~50000 connections and more than million searches per day, and absolutely no problem with lingering tcp connecs. Among the services using the LDAP we have also FreeRadius...
2010/9/22 Jim Tyrrell <jim@xxxxxxxxxxxx>
On the console I have currently configured an Idle Timeout of 300
seconds and added timeout config to the Fedora OS:
tcp_keepalive_time = 600
tcp_keepalive_intvl = 75
tcp_keepalive_probes = 9
Why are these connections not timing out after the Idle time? At the
moment I am having to regularly restart the directory service in order
to clear the connections down.
Thanks.
Jim.
--
389 users mailing list
389-users@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/389-users
-- 389 users mailing list 389-users@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/389-users
