On 11/18/22 9:07 AM, Tobias Ernstberger
wrote:
We are using 1.3.8.4 - any remarks regarding this version?
This is a very old version. It might even be using the
"nunc-stans" connection handler which was removed in newer
versions because of stability issues. Check this setting under
cn=config: nsslapd-enable-nunc-stans
If it is set to "on", try setting it to "off", which requires a
restart, and see how the server behaves.
Note the 1.3.x series is no longer maintained. At least try and go to 1.3.10 if you must stay on 1.3.x, but you should seriously look into 389-ds-base-2.x series...
HTH,
Mark
To avoid idle/stale connections we've set nslapd-ideltimeout and we see now a lower average number of open connections, so this is a first improvement. We also plan to look into nslapd-ioblocktimeout. Mit freundlichen Grüßen / Kind regards Tobias Ernstberger IT-Architect Identity and Access Management IBM Security Expert Labs +49 151 15138929 tobias.ernstberger@xxxxxxxxxx IBM Security IBM Deutschland GmbH Vorsitzender des Aufsichtsrats: Sebastian Krause Geschäftsführung: Gregor Pillen (Vorsitzender), Nicole Reimer, Gabriele Schwarenthorer, Christine Rupp, Frank Theisen Sitz der Gesellschaft: Ehningen / Registergericht: Amtsgericht Stuttgart, HRB 14562 / WEEE-Reg.-Nr. DE 99369940 https://www.ibm.com/privacy/us/en/ -----Original Message----- From: Mark Reynolds <mareynol@xxxxxxxxxx> Sent: Samstag, 12. November 2022 22:29 To: General discussion list for the 389 Directory server project. <389-users@xxxxxxxxxxxxxxxxxxxxxxx>; Tobias Ernstberger <tobias.ernstberger@xxxxxxxxxx> Subject: [EXTERNAL] Re: [389-users] FileDescriptors exhausted What version of 389-ds-base are you using? In newer versions we automatically set the server FD limit to the maximum allowed per process. This can be seen in the errors log at server startup: For example: [09/Nov/2022:16:23:07.100244932 -0500] - INFO - main - Setting the maximum file descriptor limit to: 524288 389-ds also has no issues with handling 1000's of concurrent connections. So I suspect this is just a tuning issue, but let us know what version you are running so we can give you the proper tuning advice. Now if you have issues with idle/stale connections, or bad clients, then look into tuning nsslapd-ioblocktimeout (e.g. 10000 => 10 seconds), and maybe nslapd-idletimeout. Mark On 11/11/22 9:25 AM, Tobias Ernstberger wrote:Hello, we're observing the following error message: "ERR - accept_and_configure - PR_Accept() failed, Netscape Portable Runtime error -5971 (Process open FD table is full.)" Looks like the file descriptors are exhausted, probably mainly used by incoming TCP Connections (based on our investigation regarding open FDs). We've set (and checked using the runtime information in /proc/PID/limits) the ulimits and the nsslapd-maxdescriptors to many thousands (while having about 1000 open connection regularly) We are investigating in multiple directions here, and have some questions - any input is appreciated: 1) We acknowledge that exhausted FDs prevent additional connections to be opened. But we also see, that existing connections are getting unusable, too. Is this a known behaviour? Can this be avoided? 2) Is there any chance to limit the number of open connections (lower than the max FDs)? (trying to achieve that existing connections still work) 3) What are best practice to prevent the ldap server from getting completely useless (until restart) if a client opens many connections? 4) Any additional remarks to prevent this situation? Kind regards Tobias Ernstberger IBM Security IBM Deutschland GmbH Vorsitzender des Aufsichtsrats: Sebastian Krause Geschäftsführung: Gregor Pillen (Vorsitzender), Nicole Reimer, Gabriele Schwarenthorer, Christine Rupp, Frank Theisen Sitz der Gesellschaft: Ehningen / Registergericht: Amtsgericht Stuttgart, HRB 14562 / WEEE-Reg.-Nr. DE 99369940 https://www.ibm.com/privacy/us/en/ _______________________________________________ 389-users mailing list -- 389-users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to 389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: INVALID URI REMOVED t.org_en-2DUS_project_code-2Dof-2Dconduct_&d=DwIDaQ&c=jf_iaSHvJObTbx-s iA1ZOg&r=QvSqS0gPOnxXMMO9G-eW10oOiG0sRPGfH9BtVh8hhnU&m=DMcmEB9W7URvfQb HvIjH7QUwVBMYM4zrzEUoukXTViUo_rPc8hdPmOLfpSDFOzwp&s=nl0Y6bzC4oV7Fq65kK 7mta567ymyCTlvchXpD0lpfFI&e= List Guidelines: INVALID URI REMOVED _wiki_Mailing-5Flist-5Fguidelines&d=DwIDaQ&c=jf_iaSHvJObTbx-siA1ZOg&r= QvSqS0gPOnxXMMO9G-eW10oOiG0sRPGfH9BtVh8hhnU&m=DMcmEB9W7URvfQbHvIjH7QUw VBMYM4zrzEUoukXTViUo_rPc8hdPmOLfpSDFOzwp&s=amrVoneRH3WfaEhePWxL_VqAjZb Va4T7DQmwg3u1pAg&e= List Archives: INVALID URI REMOVED ct.org_archives_list_389-2Dusers-40lists.fedoraproject.org&d=DwIDaQ&c= jf_iaSHvJObTbx-siA1ZOg&r=QvSqS0gPOnxXMMO9G-eW10oOiG0sRPGfH9BtVh8hhnU&m =DMcmEB9W7URvfQbHvIjH7QUwVBMYM4zrzEUoukXTViUo_rPc8hdPmOLfpSDFOzwp&s=9R 1JhXk09rfm36xJCxqGK_IWV2xcxHge0HfTDPNyY0s&e= Do not reply to spam, report it: INVALID URI REMOVED 2Dinfrastructure_new-5Fissue&d=DwIDaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=QvSqS 0gPOnxXMMO9G-eW10oOiG0sRPGfH9BtVh8hhnU&m=DMcmEB9W7URvfQbHvIjH7QUwVBMYM 4zrzEUoukXTViUo_rPc8hdPmOLfpSDFOzwp&s=519Dp4E1pshVxNLpfuS0Cr3H0j8WpKYQ RbBGujE7X1U&e=-- Directory Server Development Team _______________________________________________ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
-- Directory Server Development Team
_______________________________________________ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
