I'm pretty sure I've tracked this problem down. With my non-threaded bind9 running under strace, I've found it blocked in a write() call to the syslog socket. Looking at the syslog daemon, it's doing a blocking DNS lookup, which requires a response from named (currently blocked on syslog) to complete. Both processes will be stuck until syslog's name lookup either completes or times out.
The bad behavior when running a threaded named is unpredictable. In some instances a single query might take longer than usual. In others, the recvQ on a particular socket seems to back up. In some other instances, named grinds to a complete halt and won't service any name lookups or even rndc requests. I'm suspecting the unpredictable behavior is because the thread which is blocked writing to syslog continues to hold whatever locks it had before it got stuck. Behavior with a non-threaded bind is more predictable - named is blocked for roughly however long it takes syslog's name lookup to time out. Logging through syslog from named as currently implemented is a deadlock prone and unreliable configuration which should not be the default. The squid hangs I mentioned in my earlier message to this bug is also caused by syslog being blocked on name resolution. It seems squid uses syslog for some things without being explicitly configured to do so. I'll open a seperate bug against squid. -- Brian Ristuccia [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
