Date: Thu, 3 Aug 2006 07:36:18 +0200 (CEST) From: freebsd-cvs-src@oldach.net (Helge Oldach) To: ume@FreeBSD.org (Hajimu UMEMOTO) Cc: cvs-src@FreeBSD.org, scottl@samsco.org, kensmith@cse.Buffalo.EDU, cvs-all@FreeBSD.org, src-committers@FreeBSD.org Subject: Re: 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 Message-ID: <200608030536.k735aIT3081092@sep.oldach.net> In-Reply-To: <ygelkqrr1lv.wl%ume@mahoroba.org> from Hajimu UMEMOTO at "Jul 18, 2006 1:14:20 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
Hajimu UMEMOTO: > >>>>> On Mon, 17 Jul 2006 18:47:06 -0600 > >>>>> Scott Long <scottl@samsco.org> said: > > scottl> Well then you've introduced a compatibility regression in the stable > scottl> branch. Did you give this patch to the ports team to test first? If > scottl> not, then you passed the problem on to them to try to correct, which is > scottl> a bit anti-social. Also, what about people trying to compile software > scottl> outside of the ports tree? > > No, I didn't. But, most of build failure on 7-CURRENT because of this > issue, detected on pointyhat were already fixed, and seeing > __FreeBSD_version for RELENG_6 will solve it. I'm working on it now, > and when ready, I'll sent the patches to the maintainers. 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, for example: 713 ?? Ss 0:01.05 sendmail: accepting connections (sendmail) 717 ?? Is 0:00.02 sendmail: Queue runner@00:30:00 for /var/spool/client 31747 ?? I 0:00.00 sendmail: startup with 71.119.31.81 (sendmail) 32834 ?? I 0:00.00 sendmail: startup with 83.36.190.38 (sendmail) 33569 ?? I 0:00.00 sendmail: startup with 221.206.76.60 (sendmail) 34023 ?? I 0:00.00 sendmail: startup with 49.195.192.61.tokyo.flets.alph 34459 ?? I 0:00.00 sendmail: startup with 221.165.35.46 (sendmail) 36517 ?? I 0:00.00 sendmail: startup with 61.192.180.137 (sendmail) 38722 ?? I 0:00.00 sendmail: startup with 203.177.238.78 (sendmail) 39126 ?? I 0:00.00 sendmail: startup with 222.90.251.185 (sendmail) 39203 ?? I 0:00.00 sendmail: startup with 221.9.214.183 (sendmail) 39859 ?? I 0:00.00 sendmail: startup with 59.20.101.111 (sendmail) 41090 ?? I 0:00.00 sendmail: startup with 61.192.166.235 (sendmail) 41766 ?? I 0:00.00 sendmail: startup with 68.118.52.132 (sendmail) 42482 ?? I 0:00.00 sendmail: startup with 219.249.201.36 (sendmail) 42483 ?? I 0:00.00 sendmail: startup with 219.249.201.36 (sendmail) 43467 ?? I 0:00.00 sendmail: startup with 210.213.191.70 (sendmail) 43757 ?? I 0:00.00 sendmail: startup with 220.189.144.7 (sendmail) 44176 ?? I 0:00.00 sendmail: startup with 71.205.226.98 (sendmail) 44850 ?? I 0:00.00 sendmail: startup with 72.89.135.133 (sendmail) 44943 ?? I 0:00.00 sendmail: startup with 220.167.134.212 (sendmail) 48031 ?? I 0:00.00 sendmail: startup with 60.22.198.23 (sendmail) On one busy sendmail box I've seen literally thousands of such processes. Note that these processes don't disappear, so it is not related to sendmail.cf's timeouts. Broswing through the recent STABLE commits, I firstly thought it was related to the recent socket code changes, but no, it's not. It is definitely this introduction of BIND9's resolver. If I back out this change, all is fine again. As said, this is a very recent 6-STABLE. I'm tracking CTM, not cvs. I would seriously suggest to more thoroughly test this. I'm not asking to back it out right now, but this is definitely a breakage in 6-STABLE that should be fixed before 6.2. Regards, Helge
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200608030536.k735aIT3081092>