At Wed, 30 Jul 2008 18:44:47 +0200,
Thomas Jacob wrote:

> > > We checked the FD_SETSIZE-Param, its about 1024.
> > > ulimit -n is set to 16384.
> > > Has anybody an idea how to increase the FD_SETSIZE on debian
> > > or how to handle more than 1024 sockets for bind?

> >
> > I'm given to understand that Linux doesn't support increasing
> > FD_SETSIZE on the fly; you have to rebuild the system to do that.

> Actually that's not what I get from skimming through
> the kernel and bind sources. It's bind that using the
> predefined FD_SETSIZE as a hard limit, not Linux.

There's some misunderstanding here. What Evan meant (which is
actually what I told him) is that building bind with -DFD_SETSIZE=xxxx
doesn't work as expected in Linux (while this works for many other
OSes). And 'rebuilding the system' has a larger sense, including
modifying system's header file; as we saw in other messages in this
thread, we can do the trick by modifying some .h file under
/usr/include, which is a 'rebuilding a system' in his (my)

> > The -P2 versions of the patches, which are in internal testing now and
> > (barring catastrophe) should be released in two more days, have a
> > workaround for this. If you set ISC_SOCKET_FDSETSIZE to a value
> > larger than the existing FD_SETSIZE, it'll use that value instead.
> > So, for example:
> >
> > $ STD_CDEFINES="-DISC_SOCKET_FDSETSIZE=4096" ./configure

> Which probably means that I am right, since recompiling your
> systems probably isn't a requirement for -P2...

I don't understand the comment, but anyway: Linux doesn't allow
'-DFD_SETSIZE=xxxx' to work, but accepts a larger size of fd_set than
FD_SETSIZE in select(). -DISC_SOCKET_FDSETSIZE=xxxx tells BIND9 to
use the specified fd_set size for select(), regardless of the value of

To summarize, if one wants to have more than FD_SETSIZE descriptors
(most of which are sockets) in Linux,

- on P1, some system header file must be modified, or the system has
to be 'rebuilt' in some way.
- on P2, one can use -DISC_SOCKET_FDSETSIZE=xxxx without touching any
other parts of the OS

JINMEI, Tatuya
Internet Systems Consortium, Inc.