1024 threads/connections/file_descriptor limit on linux [solution]

[Konrads.Smelkovs@emicovero.com]

This is for sake of humanity :)

Symptome: daemon: 1024 beyond descriptor table size 1024\n",

The upper connection limit is set in slapd_daemon_init, specifically 
variable dtblsize. 
It is recieved by (daemon.c)
        dtblsize = sysconf( _SC_OPEN_MAX );
or 
        dtblsize = getdtablesize();
depending upon system, on my system it was by means of sysconf. Next, 
there is an extra check at 

#ifdef FD_SETSIZE    /* Always defined (on linux at least)
        if(dtblsize > FD_SETSIZE) {
                dtblsize = FD_SETSIZE;
        }


Now that we have it pinpointed, to solution. Checking with 
glibc/linuxthreads FAQ I found that it is actually defined in kernel.
So, linux-2.4.21/include/linux/limits.h and 
linux-2.4.21/include/linux/posix_types.h has FD_SETSIZE defined to to 
1024, which yours truly changed to 8192 or higher. 
Next, your /usr/include/linux should be a symlink to 
linux-2.4.21/include/linux/, in case it is not, well modify the limits.h 
and posix_types.h to that value. Moving along, on my redhat 
/usr/include/bits/types.h has __FD_SETSIZE set to 1024, change that too. 

The only thing i didn't find out (didn't try hard either), was the 
_SC_OPEN_MAX definition chain. So i just added an extra 

#ifdef CUSTOM_OPEN_MAX 
        dtblsize = CUSTOM_OPEN_MAX 
in the beginning on the dtblsize allocation code block.

Recompile and enjoy.

As a simple test w/o stresstest, use gdb
gdb slapd
break slapd_daemon_init
run

hit n until you spot dtblsize, now if it is set to FD_SETSIZE, means you 
forgot something :) Anyhow print out it's value, and it should be whatever 
you defined in CUSTOM_OPEN_MAX (well it's maximum will be at FD_SETSIZE, 
but i defined both equal, thus it was 8192 for me). 
I stress tested the connection amount and slapd happily opened whatever i 
requested.

Enjoy
--
Yay! I've got a flying machine! (UNIX)