JINMEI Tatuya / 神明達哉 wrote: > At Wed, 13 Aug 2008 12:28:23 -0700, > "David Sparks" <[EMAIL PROTECTED]> 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
