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

Shumon Huque shuque at isc.upenn.edu
Fri Jul 11 20:05:48 UTC 2008


On Fri, Jul 11, 2008 at 10:54:47AM +0100, Stacey Jonathan Marshall wrote:
> JINMEI Tatuya / ???? wrote:
> > At 09 Jul 2008 21:44:47 +0100,
> > Chris Thompson <cet1 at hermes.cam.ac.uk> wrote:
> >  
> >   
> >> I have observed two occurrences of this with BIND 9.4.2-P1 running under 
> >> Solaris 10_x86 even though plimit(1) clearly shows the named process 
> >> has both soft and hard limits on file descriptors set to 65536:
> >>
> >> Jul  9 20:29:09 recdns0.csx.cam.ac.uk named[18018]: [ID 873579 local7.error] 
> >>  general: error: socket: too many open file descriptors
> >> Jul  9 20:29:25 recdns0.csx.cam.ac.uk last message repeated 758 times
> >>
> >> # plimit 18018
> >> 18018:  /usr/local/BIND/bind/sbin/named -u namesrvr -c ../etc/named.conf
> >>    resource              current         maximum
> >> [...]
> >>   nofiles(descriptors)  65536           65536
> >>     
> >
> > What's the value of FD_SETSIZE?  Someone else reported that there's a
> > system that has FD_SETSIZE defaulting to 256.
> >
> > I'd also like to know that how many sockets were actually opened when
> > you saw the 'too many open file descriptors' errors.
> >
> > ---
> > JINMEI, Tatuya
> >
> >   
> /include/sys/types.h has it set to 256 under Solaris. That does appear 
> to be the value that lib/isc/unix/socket.c would use.

How so? On my Solaris 10 systems, it looks like <unistd.h> eventually
calls <sys/select.h> which sets FD_SETSIZE to 1024 (or 65536 in LP64):

	/*
	 * Select uses bit masks of file descriptors in longs.
	 * These macros manipulate such bit fields.
	 * FD_SETSIZE may be defined by the user, but the default here
	 * should be >= NOFILE (param.h).
	 */
	#ifndef FD_SETSIZE
	#ifdef _LP64
	#define FD_SETSIZE      65536
	#else
	#define FD_SETSIZE      1024
	#endif  /* _LP64 */
	[...]

I've upgraded 2 of our campus caching resolvers to 9.4.2-P1. So far
no problems. I've seen upwards of 500 open file descriptors but the
number fluctuates signficantly and on average is far below that.

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.

--Shumon.


More information about the bind-users mailing list