On Wed, Aug 28, 2019 at 03:17:05PM -0400, Allan Streib wrote: > Allan Streib <astr...@indiana.edu> writes: > > > Running a rather busy ldapd host, and seeing some hangs in responses to > > queries. > > > I see that fstat -u _ldapd always ends at FD 119 when the hang occurs: > > [...] > _ldapd ldapd 42641 112* internet stream tcp 0x0 172.16.0.169:389 <-- > 172.16.0.38:44708 > _ldapd ldapd 42641 113* internet stream tcp 0x0 172.16.0.169:389 <-- > 172.16.0.45:43392 > _ldapd ldapd 42641 114* internet stream tcp 0x0 172.16.0.169:389 <-- > 172.16.0.26:54300 > _ldapd ldapd 42641 115* internet stream tcp 0x0 172.29.202.69:389 <-- > 172.29.200.100:36250 > _ldapd ldapd 42641 116* internet stream tcp 0x0 172.29.202.69:389 <-- > 172.29.200.109:45362 > _ldapd ldapd 42641 117* internet stream tcp 0x0 172.29.202.69:389 <-- > 172.29.200.108:47864 > _ldapd ldapd 42641 118* internet stream tcp 0x0 172.29.202.69:389 <-- > 172.29.200.104:56746 > _ldapd ldapd 42641 119* internet stream tcp 0x0 172.29.202.69:389 <-- > 172.29.200.106:40436 > > > I tried the following: > > Gave _ldapd a login class of "ldap" > > Added to login.conf: > > ldap:\ > :openfiles=512:\ > :tc=daemon: > > restart ldapd. > > Still hangs with fstat output the same. >
I guess the problem is in the error handling of one of the filter codes which leaks an fd. At least I suspect that the error message about filter type is suggesting that. -- :wq Claudio
