>> 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. I found in the general log messages like this: 13-Aug-2008 07:01:01.996 general: error: socket: too many open file descriptors Why isn't the max number of fds in the error message? This would be useful for debugging because you can set this limit in many places and you don't know if it took effect or not (/etc/limits, /etc/security/limits.conf, ulimit). Daemons started during boot often get a different set of limits than ones (re)started from a shell after boot. > You should build named by setting STD_CDEFINES appropriately. For > example, if you use a sh variant (like zsh or bash): I just tried bumping this up to 16384 by patching the Gentoo ebuild. Compile lines look like this so I assume that the define is properly set: x86_64-pc-linux-gnu-gcc -I/var/tmp/portage/net-dns/bind-9.5.0_p2-r1/work/bind-9.5.0-P2 -I./include -I./../nothreads/include -I../include -I./../include -I./.. -DFD_SETSIZE=16384 -march=nocona -O2 -pipe -D_GNU_SOURCE -I/usr/include/libxml2 -W -Wall -Wmissing-prototypes -Wcast-qual -Wwrite-strings -Wformat -Wpointer-arith -fno-strict-aliasing -c app.c -fPIC -DPIC -o .libs/app.o Apparently 16384 fd isn't sufficient? I restarted named and: 13-Aug-2008 12:04:55.667 general: error: socket: too many open file descriptors >> And you may also want to check the OS capability with this tool: >> http://www.jinmei.org/selecttest.tgz ns1 selecttest # ./selecttest -r 16384 selecttest: nsocks = 4093, TEST_FDSETSIZE = -1, FD_SETSIZE = 1024, sizeof fd_set = 128 created 16384 sockets, maxfd = 16386 FD_CLR test...OK FD_SET test...OK select test...OK I doubt it ran out of fds ... either I compiled it wrong or there is something else going on. Cheers, ds
