https://bugs.openldap.org/show_bug.cgi?id=10029
Issue ID: 10029 Summary: slapd crashes when run with unlimited open files Product: OpenLDAP Version: 2.6.4 Hardware: All OS: Mac OS Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs@openldap.org Reporter: gray@nxg.name Target Milestone: ---
To reproduce:
% ulimit -n unlimited % $T/openldap-2.6.4/libexec/slapd -d-1 641ee8bc.32f05820 0x1dc760140 @(#) $OpenLDAP: slapd 2.6.4 (Mar 25 2023 12:25:49) $ openldap 641ee8bc.32f39ff8 0x1dc760140 daemon_init: <null> 641ee8bc.32f40588 0x1dc760140 daemon: SLAP_SOCK_INIT: dtblsize=-1 641ee8bc.32f43080 0x1dc760140 ch_calloc of 1 elems of 18446744073709551615 bytes failed Assertion failed: (0), function ch_calloc, file ch_malloc.c, line 107. zsh: abort $T/openldap-2.6.4/libexec/slapd -d-1
This is because `daemon.c` (line 1867) uses the maximum number of open files to set `dtblsize`, which is subsequently used to size an array:
1867 #ifdef HAVE_SYSCONF 1868 dtblsize = sysconf( _SC_OPEN_MAX ); 1869 #elif defined(HAVE_GETDTABLESIZE) 1870 dtblsize = getdtablesize(); 1871 #else /* ! HAVE_SYSCONF && ! HAVE_GETDTABLESIZE */ 1872 dtblsize = FD_SETSIZE; 1873 #endif /* ! HAVE_SYSCONF && ! HAVE_GETDTABLESIZE */
If the maximum number of FDs is unlimited, then sysconf(_SC_OPEN_MAX) returns -1, and the program crashes when it tries to malloc that much memory.
I've marked this as OS=macOS because that's what I'm illustrating this on, but the same thing would happen on any OS where the sysconf call returns a negative number for the 'unlimited' case.
https://bugs.openldap.org/show_bug.cgi?id=10029
Howard Chu hyc@openldap.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution|--- |WONTFIX
--- Comment #1 from Howard Chu hyc@openldap.org --- Obviously: don't do this. If we were going to patch for this condition, we would simply make slapd exit. Once you get above 65535 connections or so, you'll be running out of ports anyway, so "unlimited" makes no sense.
https://bugs.openldap.org/show_bug.cgi?id=10029
--- Comment #2 from gray@nxg.name gray@nxg.name --- I don't do this deliberately (I don't think it's a sensible configuration any more than you do). I ran into this when, as part of a test harness, I invoked slapd from a Make variant which 'helpfully' sets this limit to unlimited. (I think that counts as a defect in that program, and have reported it as such, but...).
So I agree with you that having this unlimited is not sensible. But it's a possible configuration, and it would seem useful for slapd to at least do a sanity check here, and if it finds an insane value to do something more useful than simply exit with an assertion violation.
Even exiting with an error would be something, as you suggest. Alternatively, calling setrlimit at this point, with an arbitrary large-ish value like 65535 would restore the process to a reasonable configuration, and be more-or-less a one-line change.
https://bugs.openldap.org/show_bug.cgi?id=10029
--- Comment #3 from Ondřej Kuzník ondra@mistotebe.net --- You won't risk running into port no. exhaustion except in small environments - even though the local part of the 4-tuple is fixed, the remote part gives you unlimited number of source ports if you have enough source addresses. Yes, cn=monitor will struggle, we've seen that, but that's a design choice of slapd's own making.
We might have to add a configuration option (and a sane default) if we get a nonsensical (especially negative) max number.
https://bugs.openldap.org/show_bug.cgi?id=10029
--- Comment #4 from Howard Chu hyc@openldap.org --- IMO we have no idea what a sane default is. On a large, 1024 core server, 1 million might be reasonable. On a small box like a raspberry pi, maybe only 128. It's up to sysadmins to pick sane settings, not for us to automagically determine them.
https://bugs.openldap.org/show_bug.cgi?id=10029
Quanah Gibson-Mount quanah@openldap.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |VERIFIED Keywords|needs_review |
-
openldap-its＠openldap.org