I would also tune the TCP heartbeat in sysctl to make it shorter rather than the idle timeout. the default is 2 hours and not to cut it off if heartbeats are missed. I prefer to make it 2 minutes and kill on the second missed heartbeat for LDAP servers. the reason for this is that there are a lot of sloppy LDAP clients out there that exit without closing their connections. btw heartbeats only happen when a TCP session is open and idle, they don't happen when there is active traffic. here is a howto that will explain more https://tldp.org/HOWTO/TCP-Keepalive-HOWTO/usingkeepalive.html Changing the TCP heartbeat settings on the server wont add any overhead because its already there in the kernel any way, also its a good way to filter out bad clients that left zombie connections open but won't break clients that are legitimately idle, but will reuse the connections later. Zombie connections are what usually cause LDAP servers to hit the max open file limit, not legitimately idle connections, so it's always a good place to start tuning your LDAP server. On Wed, Sep 1, 2021 at 10:11 AM Michael Starling <mlstarling31@xxxxxxxxxxx> wrote: > > > Hello. > > I enabled chaining in our environment to replicate password policy attributes from the consumers and hubs back to the masters and now we are seeing these errors in the logs > We have to reboot for the system to become stable again. > > > > 31/Aug/2021:23:31:36.584135966 -0400] - ERR - configure_pr_socket - Unable to move socket file descriptor 42 above 64: OS error 24 (Too many open files) > > Is this behavior expected with this change? > > Are there any other dirsrv tuning options that you think would be helpful? > > Right now, I have made the following changes. > > nsslapd-idletimeout: 600 > > > I have bumped nofile for dirsrv from 8192 to 20000. > > dirsrv - nofile 200000 > > We have also set open file limit in the service file for DS > > [Service] > LimitNOFILE=200000 > > _______________________________________________ > 389-users mailing list -- 389-users@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to 389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx > Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: https://lists.fedoraproject.org/archives/list/389-users@xxxxxxxxxxxxxxxxxxxxxxx > Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure _______________________________________________ 389-users mailing list -- 389-users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to 389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-users@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
