9.5.0-P2 and socket: too many open file descriptors

[David Sparks]

JINMEI Tatuya / 神明達哉 wrote:
> At Wed, 13 Aug 2008 12:28:23 -0700,
> "David Sparks" <dave at ca.sophos.com> wrote:
> 
>>>> Usual question:
>>>> - did you build named with a large value of FD_SETSIZE?
>> I just found out I have a similar problem with BIND 9.5.0-P2.  I have nofile 
>> set to 8192 but it doesn't seem to be respected by named?  Why does named not 
>> use the limits set by ulimit?  Distro binaries are seldom built with special 
>> defines like this set.
> 
> Because the standard API of select() doesn't ensure it works for more
> than FD_SETSIZE descriptors.  And even though we've seen reports about
> 'too many open FDs', the default maximum FD_SETSIZE should actually be
> fine for vast majority of users.  If we implicitly raise the maximum,
> possibly violating something of the system call interface, it may hurt
> such innocent users.  So we thought the default should be
> conservative.

Ah ok.  Looking at the code it seems the fd created without problems but is 
thrown away if the fileno is above FD_SETSIZE because there may be a problem 
putting more than FD_SETSIZE sockets in a select() call?


> Also, don't forget the world is not just Linux.  Solaris requires a
> compile time change to FD_SETSIZE, so it's very difficult to increase
> the limitation 100% run-time.

Why not add a configure script to determine/configure maximum values for select()?


> Nevertheless, we plan to introduce a command-line option for beta
> versions to specify the named's internal limitation run-time.  This
> would make more sense for beta because it can use newer APIs (such as
> BSD kqueue and Linux epoll) that don't have a hard limitation like
> FD_SETSIZE of select().

Great.

> Linux doesn't honor user defined FD_SETSIZE at compilation time
> (welcome to the wonderful portability mess).  You should define
> ISC_SOCKET_FDSETSIZE for Linux instead:

Thanks, that seems to have worked!

Cheers,

ds