File Descriptor limit and malfunction bind
Kevin Darcy
kcd at chrysler.com
Tue Jan 5 15:38:10 UTC 2010
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
More information about the bind-users
mailing list