Bind 8.2.2-REL eating CPU time in tight loop (HP-UX 10.20)

[Mark_Andrews at iengines.com]

> Hi,
> 
> I have a problem with bind 8.2.2-REL on HP-UX 10.20:
> At some point in time it will suddenly start to consume CPU time and
> sit in an endless loop.
> A "trace" shows:
> 21070: gettimeofday(0x7b03ab60, 0) = 0
> 21070: gettimeofday(0x7b03ace0, 0) = 0
> 21070: recvfrom(24, 0x7b03aa68, 513, 0, 0x7b03aa4c, 0x7b03aa5c) = 0
> 21070: gettimeofday(0x7b03ab60, 0) = 0
> 21070: select(26, 0x40069d58, 0x40069f58, 0x4006a158, 0x7b03aa38) = 2
> 21070: gettimeofday(0x7b03ab60, 0) = 0
> 21070: accept(25, 0x7b03aa80, 0x7b03aa7c) = -1 EAGAIN (Resource temporarily u
> navailable)
> 21070: gettimeofday(0x7b03ab60, 0) = 0
> 21070: gettimeofday(0x7b03ace0, 0) = 0
> 21070: recvfrom(24, 0x7b03aa68, 513, 0, 0x7b03aa4c, 0x7b03aa5c) = 0
> 21070: gettimeofday(0x7b03ab60, 0) = 0
> 21070: select(26, 0x40069d58, 0x40069f58, 0x4006a158, 0x7b03aa38) = 2
> 21070: gettimeofday(0x7b03ab60, 0) = 0
> 21070: accept(25, 0x7b03aa80, 0x7b03aa7c) = -1 EAGAIN (Resource temporarily u
> navailable)
> Besides this problem, queries are answered fine.
> I have identical named(s) running on approx 20 hosts at two sites and only
> one named at one site (the one with the most queries) will exhibit this
> problem, even though I don't know how to trigger it myself.
> The problem occured sind changing to Bind 8.x and in the mailing list
> I found other reports about similar problems on different OS but unfortunatel
> y
> without solutions.
> What can I do? I did attach the debugger but unfortunately I don't have
> symbols in it.
> Just a (stupid?) idea, but why is select dealing with descriptor 26 while
> later accept is used on descriptor 25??

	No, it is saying check the first 26 file descriptors 0..25
	for activity.  It finds activity on 2 file descriptors 24
	and 25.  24 is a udp socket, 25 is a tcp socket listening
	for connections.

	What is interesting about this is the recvfrom is return
	0 to the first call and accept is returning EAGAIN.  Select
	has just returned 2 so neither of these conditions should
	be occuring normally.

	The recvfrom could be due to zero length udp packets and
	the EAGAIN could be due to TCP sessions that are being
	reset.  I suspect that you are under attack which named is
	successfully repelling.  A packet trace may show some pattern.

	Mark
> 
> Best regards,
> 	Lutz Jaenicke
> -- 
> Lutz Jaenicke                             Lutz.Jaenicke at aet.TU-Cottbus.DE
> BTU Cottbus               http://www.aet.TU-Cottbus.DE/personen/jaenicke/
> Lehrstuhl Allgemeine Elektrotechnik                  Tel. +49 355 69-4129
> Universitaetsplatz 3-4, D-03044 Cottbus              Fax. +49 355 69-4153
> 
--
Mark Andrews, Internet Engines Inc. / Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews at iengines.com