Re: FileDescriptors exhausted
by Mark Reynolds
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(a)lists.fedoraproject.org
> To unsubscribe send an email to 389-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.fedoraproje...
> Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
--
Directory Server Development Team
1 year, 5 months
Re: FileDescriptors exhausted
by Howard Chu
> Date: Fri, 11 Nov 2022 14:25:57 +0000
> From: Tobias Ernstberger <tobias.ernstberger(a)de.ibm.com>
> 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:
Have you checked with e.g. lsof to see where all the FDs are being used? If you think there's only 1000
incoming connections, probably there are other things going on e.g. DNS reverse lookups on client
addresses, miscellaneous other files being opened, etc.
>
> 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?
Fyi, OpenLDAP has no issue with multiple thousands of FDs being served concurrently...
>
>
> 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/
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
1 year, 5 months
Re: FileDescriptors exhausted
by Adoni Elohim
Unauthorized Luke's gone until his ass stays away from my shit my kids
there mom's as well including Cierra
On Fri, Nov 11, 2022, 6:26 AM Tobias Ernstberger <
tobias.ernstberger(a)de.ibm.com> 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(a)lists.fedoraproject.org
> To unsubscribe send an email to 389-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.fedoraproje...
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>
1 year, 5 months
FileDescriptors exhausted
by Tobias Ernstberger
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/
1 year, 5 months
Upgrading from 1.2.2 to 1.4.4
by Julian Kippels
Hi,
I am currently in the process of moving our LDAP-Servers from old
CentOS 7 Servers to new Debian 11 Servers. In the process I am
exporting all databases from the old server to ldif files and importing
those files on the new server.
When I import such a file I get a lot (basically for every single entry)
of warnings and errors in the errors-log like the following:
[08/Nov/2022:21:01:52.272475719 +0100] - ERR - oc_check_allowed_sv - Entry "cn=219058,ou=accounts,o=demo" -- attribute "entrylevelrights" not allowed
[08/Nov/2022:21:01:52.273547001 +0100] - WARN - import_producer - import demo: Skipping entry "cn=219058,ou=accounts,o=demo" which violates schema, ending line 9232514 of file "/var/lib/dirsrv/slapd-ldap-master/ldif/demo.ldif"
I can't make heads or tails of this. I exported the ldif using the
389-console using "Export Databases" and I import them via Cockpit
using "Initialize Suffix" for the Suffix o=demo
I cannot find this attribute in any schema-file on either the old or
the new servers. Where does this come from, and how do I solve this
issue?
Thanks in advance
Julian
1 year, 5 months