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]

Hajimu UMEMOTO:
> >>>>> On Thu, 3 Aug 2006 07:36:18 +0200 (CEST)
> >>>>> Helge Oldach <freebsd-cvs-src at oldach.net> said:
> 
> freebsd-cvs-src> Well... I've spotted a regression not with the ports tree but with
> freebsd-cvs-src> 6-STABLE. On several boxes with this change applied I see lots of
> freebsd-cvs-src> sendmails stacking up over time, for example:
> 
> Could you show me your resolv.conf?  Are all nameservers listed in
> your resolv.conf available?

Yes, certainly. As I've said, this issue shows up on several boxes. This
includes machines with only a single resolver (which is up of course),
resolving towards the internet, machines that talk to localhost (running
a caching named with forwarders to public servers), but also to machines
running on an internal network with private root servers. Actually I had
already played around a bit with this, without any noticeable effect.

OTOH, if one or all of the resolvers were just not available, the
process should never get stuck indefinitely, but should log a message at
least.

> freebsd-cvs-src> On one busy sendmail box I've seen literally thousands of such
> freebsd-cvs-src> processes. Note that these processes don't disappear, so it is not
> freebsd-cvs-src> related to sendmail.cf's timeouts.
> 
> Dou you mean that the processes are never disappered except killing
> them?

Exactly.

> Which status are they?

ps shows them as "I". See my other mail on more explanations. They
disappear from netstat after some time. Once killed, they "normally"
terminate their TCP session. Note that not only sendmail is affected but
other processes that do name resolution as well.

I have a test box that I can play with to spot more details, if that helps.

Helge