8.2.2-P5 Solaris2.6 db_load problems

[Jim Reid]

>>>>> "Heikki" == Heikki Hannikainen <hessu at hes.iki.fi> writes:


    Heikki> On Wed, 26 Apr 2000, Jim Reid wrote:
    >> >>>>> "Heikki" == Heikki Hannikainen <hessu at hes.iki.fi> writes:
    >> 
    Heikki> 26-Apr-2000 14:49:28.840 load: db_load could not open:
    Heikki> domain.fi.le: Resource temporarily unavailable
    >>  Looks like your 2.6 box is running out of file
    >> descriptors. Check the man page for open() and find out why it
    >> returns EAGAIN: "Resource temporarily unavailable". You
    >> probably have to fix some kernel value to increase the number
    >> of file descriptors. Or you could use lsof to find out where
    >> they've all gone.

    Heikki>   Okay, i found the problem. It's not the kernel limits
    Heikki> (they've been increased anyway over the defaults), but the
    Heikki> fact that db_load uses stdio's fopen() to open the db
    Heikki> files on disk. And Solaris (2.5.1 and 2.6 at least) STDIO
    Heikki> has a limit of 255 files (see stdio(3S)):

That's not the problem. 255 descriptors should be more than enough for
a name server. The problem for you is that 255 descriptors are not
enough: something's making your name server use an unusually high
number of descriptors.

    Heikki>   Now, the strange thing is that lsof shows a LARGE number
    Heikki> of TCP connections (established and SYN_SENT) to the
    Heikki> domain port of a single other DNS server, for which i can
    Heikki> find NO slave entries in my configuration.

What's connecting to that "other DNS server", your name server?

    Heikki>   So, two problems... one would need to skip using stdio,
    Heikki> or perhaps link against something like the sfio library

That wouldn't be wise.

    Heikki> Second, why do all these TCP connections take place...

Yes. Try turning up the debugging and tracing in your name server to
see what's going on. DNS uses TCP for zone transfers or for answers
that need more than 512 bytes. It would be very odd if your name
server was making a few hundred TCP connections - to the same address?
- at once.