cvs commit: src/sys/sys param.h src/include Makefile netdb.h res_update.h resolv.h src/include/arpa inet.h nameser.h nameser

[Helge Oldach]

Robert Watson:
> > Well... I've spotted a regression not with the ports tree but with 6-STABLE. 
> > On several boxes with this change applied I see lots of sendmails stacking 
> > up over time

Just like to add that I've seen this with other processes as well, e.g.
with ftp jobs that pick up the latest CTM deltas via cron. They get
stuck in an early TCP phase. Guessing from tcpdumps it's right after the
initial handshake. In netstat they show up as ESTABLISHED.

> We only concluded that it was not a kernel socket bug a day or so ago, so I'm 
> not sure he's had a chance to generate a resolver bug report.  He reported 
> that the application appeared to have two connected UDP sockets for name 
> resolution, and one bad name server entry, but that the resolver appeared to 
> be blocked in a read on the UDP socket that didn't have data queued, rather 
> than the one that did.

So it seems. To add another observation: In netstat, the entries
relating to the processes disappear after some time. The sockets clear
up, but the process is still stuck. Also the UDP socket (resolver
queries) disappears.

Once I kill one such process, however, it sends a FIN packet and the TCP
socket shows up again in netstat. So it's not completely dead but "just"
stuck.

I don't have a clue what is going on. Maybe it's not related to the
resolver update, but this update just triggers another issue. I'm no
resolver expert, but didn't BIND9 implement a new event library? On
another occasion I had the vague feeling that it might be related to the
calcru issue that was discussed in several threads recently.

Just to verify that the issue hadn't been caught in the meantime I built
a system from yesterday's 6-STABLE, but the issue is still present. :-(

Helge