#392 Directory server not closing file handles
Closed: wontfix None Opened 11 years ago by rmeggins.

https://bugzilla.redhat.com/show_bug.cgi?id=825863 (Red Hat Enterprise Linux 6)

Description of problem:

The directory server processes on IPA servers don't seem to close file handles
properly so given enough time they run into the nofiles limit of 8192 at which
point they become unresponsive until the process is restarted.

The deleted (but not closed) files are named as /var/tmp/ldap_49X

Version-Release number of selected component (if applicable):
389-ds-base-1.2.9.14-1.el6_2.2.x86_64
389-ds-base-libs-1.2.9.14-1.el6_2.2.x86_64

How reproducible:

Always

Steps to Reproduce:
1. start IPA
2. run for x in `seq 1 100000` ;do ipa user-find > /dev/null 2>&1 ; done
3. ls -l /proc/<pidof ds slapd>/fd

Actual results:

The number of open file handles (deleted files) keep on increasing and slapd
stop responding when it reaches the max open file limit.

Expected results:

DS closes the file handles properly

Additional info:

I am unable to re-produce the issue completely, ie; on my test machines (with
less activities) the number of open file handles (of deleted file) are less
than 20, but we could create ~20 open file handles (of deleted files) by simply
executing a ipa user-find command in loop.

gdb stack traces of open /var/tmp/ldap_499
ticket-392.log

set default ticket origin to Community

This is a kerberos bug, not a 389 bug

Metadata Update from @rmeggins:
- Issue assigned to rmeggins
- Issue set to the milestone: N/A

7 years ago

389-ds-base is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in 389-ds-base's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/389ds/389-ds-base/issues/392

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.

Metadata Update from @spichugi:
- Issue close_status updated to: wontfix (was: Invalid)

3 years ago

Login to comment on this ticket.

Metadata