Too many open files (not only BIND 9.5.0-P1)

[Shumon Huque]

On Sat, Jul 12, 2008 at 08:45:30AM +1000, Mark Andrews wrote:
> > I am concerned about upgrading my primary resolver though, which
> > is higher traffic. If I exceed 1024, what is the recommended action?
> > Redefine FD_SETSIZE upwards and recompile? Recompiling in 64-bit
> > sounds scarier.
> 
> 	Named is regularly compiled as a 64 bit binary.  You just
> 	need to specify the right compiler flags and have 64 bit
> 	versions of the libraries it links in.

Thanks. My question was specifically about 64-bit on Solaris, since
most user mode programs on that platform are typically compiled and
tested as 32-bit. If you're saying that Solaris installations routinely 
run 64-bit BIND and it's well tested, then my concerns are alleviated.

In case others are trying it, here's how I compiled a 64-bit BIND, with 
the Sun C compiler and the Sun openssl libraries in /usr/sfw:

SPARC:
        env CC=cc CFLAGS="-xarch=generic64" \
                LDFLAGS="-L/usr/sfw/lib/sparcv9 -R/usr/sfw/lib/sparcv9" \
                ./configure --with-openssl=/usr/sfw ....

AMD64:
        env CC=cc CFLAGS="-xarch=generic64" \
                LDFLAGS="-L/usr/sfw/lib/amd64 -R/usr/sfw/lib/amd64" \
                ./configure --with-openssl=/usr/sfw ....

I'm not sure why the Solaris linker doesn't automatically search
64-bit architecture specific subdirectories in /usr/sfw (like it
does for /lib and /usr/lib). Otherwise those wouldn't need to be
separately specified with LDFLAGS. Or BIND's autoconfig could allow
separate specification of the openssl library and include-file 
directories, in which case you could use something like:

	./configure --with-openssl-lib=/usr/sfw/lib/sparcv9 \
		--with-openssl-inc=/usr/sfw/include

--Shumon.