Bind 8.2.1 stability problem!

Erik Bos erik at xs4all.net
Mon Jul 12 20:56:15 UTC 1999


Roberto Turriziani <r.turriziani at gmx.ch> writes:

>Recently we changed our DNS-Servers from
>    SparcStation-5 96 MB 100MBit-half switched
>    SUN/Solaris 2.5
>    Bind 8.1.2
>to
>    HP LPr Pentium 450MHz 256MB 100MBit-full switched
>    RedHat 6.0 Kernel 2.2.10
>    Bind 8.2.1
>to achive better performance for the about 4500 zones we host.

>But instead of better performance, we ran into troubles:

>Sometimes bind on our primary server seems to hang. In debugging mode
>the incoming requests are logged, but the daemon doesn't answer
>anything. After a while (between 1 and 5 minutes) it recovers and starts
>to answer queries again. In the logfile suddenly appears a bunch of the
>following messages:

[ ...]

>There's a second problem, that occurs when  I try to reload the server;
>it hangs suddenly and never logs a line. The only solution is to stop
>and start bind.

I've seen this behaviour as well on both SunOS 4.1.3U1, Linux 2.0.36 (and
probably BSD/OS as well), named just hangs after a reload, stracing the
process helps it to recover:

after "ndc reload", named hangs:

[root at bla tmp]# strace -p 29049
fcntl(6, F_GETFL)                       = 0x802 (flags O_RDWR|O_NONBLOCK)
close(6)                                = 0
fcntl(7, F_GETFL)                       = 0x802 (flags O_RDWR|O_NONBLOCK)
close(7 <unfinished ...>

strace stopped, and started again:

[root at bla tmp]# strace -p 29049  
fcntl(8, F_GETFL)                       = 0x802 (flags O_RDWR|O_NONBLOCK)
close(8)                                = 0
brk(0x8172000)                          = 0x8172000
fcntl(9, F_GETFL)                       = 0x802 (flags O_RDWR|O_NONBLOCK)
close(9)                                = 0
fcntl(10, F_GETFL)                      = 0x802 (flags O_RDWR|O_NONBLOCK)
close(10)                               = 0
gettimeofday({931792119, 692762}, NULL) = 0
sigprocmask(SIG_BLOCK, [HUP INT ILL USR1 USR2 PIPE TERM CHLD XFSZ WINCH], NULL) 

named continues...



More information about the bind-users mailing list