389 ds ignores nsslapd-maxdescriptors

[resposit]

Issue Description
389 ds 2.3.6 seems to ignore nsslapd-maxdescriptors=32768

Package Version and Platform:

• Platform: RockyLinux 9.3
• Package and version: 389-ds-base-2.3.6-3.el9_3.x86_64

Steps to Reproduce
In /etc/systemd/system/dirsrv@cloud20.service.d/override.conf I have:

[Service]
LimitNOFILE=32768
LimitNPROC=16384

In dse.ldif I have:

nsslapd-maxdescriptors: 32768
nsslapd-reservedescriptors: 16384

When start directory server:
systemctl start dirsrv@cloud20.service

I get the error:
[12/Dec/2023:13:00:09.358667991 +0100] - ERR - slapd_daemon - Not enough descriptors to accept any connections. This may be because the maxdescriptors configuration directive is too small, the hard limit on descriptors is too small (see limit(1)), or the reservedescriptors configuration directive is too large. Try increasing the number of descriptors available to the slapd process. The current value is 16384. 16384 descriptors are currently reserved for internal slapd use, so the total number of descriptors available to the process must be greater than 16384.
It seems 389 ds ignores the setting nsslapd-maxdescriptors=32768 and considers nsslapd-maxdescriptors=16384. In fact I change in dse.ldif:

nsslapd-maxdescriptors: 32768
nsslapd-reservedescriptors: 8192

Then the server starts properly. Strangely it then reports the correct nsslapd-maxdescriptors value:

[root@cloud20 etc]# dsconf -D "cn=Directory Manager" ldap://localhost config get nsslapd-maxdescriptors
Enter password for cn=Directory Manager on ldap://localhost:
nsslapd-maxdescriptors: 32768

Additional context
I have a twin server (same configuration) running 389-ds-base-2.2.9-2.el8.x86_64 and I have no such issue

[progier389]

Indeed nsslapd-maxdescriptors is no more used ( that is the nofile hard limit that matters)
In fact I suspect that your problem is not about the nsslapd-maxdescriptors but that the nsslapd-reservedescriptors meaning has unexpectedly changed.
In older version it was the number of file descriptors used for the db, log files, import/export file, ... but NOT for the connections sockets while now it seems to also include the sockets
(in other words nsslapd-reservedescriptors now acts as nsslapd-maxdescriptors was )

Should double check with @jchapma who worked on these part, but I think something is now broken.

[jchapma]

Looking into this

[jchapma]

Hi @resposit

Bit of background
The connection table is an internal table used to manage active connections to the server, its size is determined at startup: connection table size = (num max descriptors - num reserve descriptors)

The bug you found was due to the value of nsslapd-reservedescriptors being relatively high, which is perfectly fine. In this scenario, the server failed to start due to a comparison of the connection table size and the number of reserve descriptors. Now we check that the connection table size is < (max descriptors - reserve descriptors)

Thanks

[jchapma]

1483a6a..907bd85 389-ds-base-3.0 -> 389-ds-base-3.0
7165694..c141e70 389-ds-base-2.5 -> 389-ds-base-2.5
3ea52a1..6a7d13d 389-ds-base-2.4 -> 389-ds-base-2.4
604360c..19488f4 389-ds-base-2.3 -> 389-ds-base-2.3

389-ds-base-2.2: Hardcoded with a single connection list.