named crashing with too many open files

[Danny Mayer]

		I'm bothered by the fact that named does not seem to be closing the
  socket or file if they're not in use.  Since noone else is seeing this
could there
  be something wrong with your configuration.

			Danny

At 06:41 PM 10/27/00 -0400, Ben Stern wrote:
>
>On Fri, Oct 27, 2000 at 11:33:51PM +0100, Jim Reid wrote:
>> This doesn't mean a thing. It's quite common for some folk's name
>> servers to be unreachable. Your name server will not specially create
>> a unique socket (file descriptors) when sending UDP queries to another
>> server. It uses one socket for all outbound queries. This means file
>> descriptors should get used up talking to those unreachable
>> servers. However named could use a file descriptor for each TCP
>> connection it tries to initiate to those dead/unreachable servers. But
>These are TCP connections.
>
>> those descriptors would be recycled after a few minutes when the TCP
>> connections fail and their PCBs get torn down. And anyway it would
>> take an awful lot of zone transfers requests or truncated replies from
>> those servers - TCP traffic - to account for file descriptor
>> exhaustion.
>I know - that's why I'm confused.  It *is* opening a few hundred TCP
>connections to these servers.
>
>> How do you *know* it's wasting open files on these dead hosts? Where's
>> the proof? If this really is the problem - I doubt it - then you can
>> use server{} statements to mark them as bogus. And if their IP
>Testing that right now.
>
>> addresses are listed in zone{} statements, you could remove them.
>> What did lsof have to say about the descriptors named was using?
>Either ESTABLISHED - which I don't get, since I cannot telnet to that's
>server's port 53, or CLOSE_WAIT.
>
>> Could you have lots of inbound TCP connections to the name server, ie
>> lots of incoming zone transfer requests?
>It's a possiblity.  None of these servers are actually listed in the
>named.conf, other than the bogus statements I added, so they may be flooding
>it.
>
>Thank you!
>Ben Stern
>