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
[email protected]
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<[email protected]>
Sent: Samstag, 12. November 2022 22:29
To: General discussion list for the 389 Directory server
project.<[email protected]>; Tobias
Ernstberger<[email protected]>
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 [email protected] To
unsubscribe send an email [email protected]
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 [email protected]
To unsubscribe send an email [email protected]
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/[email protected]
Do not reply to spam, report
it:https://pagure.io/fedora-infrastructure/new_issue
--
Directory Server Development Team
_______________________________________________
389-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]
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/[email protected]
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
