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(a)de.ibm.com
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(a)redhat.com>
Sent: Samstag, 12. November 2022 22:29
To: General discussion list for the 389 Directory server
project.<389-users(a)lists.fedoraproject.org>; Tobias
Ernstberger<tobias.ernstberger(a)de.ibm.com>
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
99369940https://www.ibm.com/privacy/us/en/
> _______________________________________________
> 389-users mailing list --389-users(a)lists.fedoraproject.org To
> unsubscribe send an email to389-users-leave(a)lists.fedoraproject.org
> 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(a)lists.fedoraproject.org
To unsubscribe send an email to389-users-leave(a)lists.fedoraproject.org
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@lists.fe...
Do not reply to spam, report it:https://pagure.io/fedora-infrastructure/new_issue