File Descriptor limit and malfunction bind

[Kevin Darcy]

Shumon Huque wrote:
> On Mon, Jan 04, 2010 at 01:43:52PM -0500, Kevin Darcy wrote:
>   
>> named seems to use, by default, the OS hard limit on file descriptors, 
>> even though the ARM says "The default is |unlimited|. ". When it starts 
>> up as superuser, in theory it should be able to set both the hard and 
>> soft limit to "infinity", but it doesn't appear to be doing that, at 
>> least it doesn't on Solaris.
>>     
>
> This is not my experience on Solaris 10. According to the code, if
> undefined in the config file, it's raising them to RLIM_INFINITY 
> (lib/isc/unix/resource.c), and that's what I observe on my servers:
>
> 	$ plimit `pgrep named`
> 	23385:  /usr/local/sbin/named
> 	   resource              current         maximum
> 	  time(seconds)         unlimited       unlimited
> 	  file(blocks)          unlimited       unlimited
> 	  data(kbytes)          unlimited       unlimited
> 	  stack(kbytes)         unlimited       unlimited
> 	  coredump(blocks)      unlimited       unlimited
> 	  nofiles(descriptors)  unlimited       unlimited
> 	  vmemory(kbytes)       unlimited       unlimited
>
> The invoking environment had nofiles settings of 256 (soft) and
> 65536 (hard) respectively, which appear to be the OS defaults.
>
>   
I was accidentally running a very old version of BIND on my test box 
(9.3.2), even though I was quoting the documentation from a later version.

You are correct, since at least 9.4.3-P4 (the lowest-numbered supported 
version of BIND), named seems to raise the limit to "infinity", as the 
documentation states.

Sorry for the confusion.

- Kevin