From owner-freebsd-net Thu Oct 25 21:52:25 2001 Delivered-To: freebsd-net@freebsd.org Received: from dms-lcc-vck-m1.dms.usace.army.mil (dms-lcc-vck-m1.dms.usace.army.mil [155.76.29.50]) by hub.freebsd.org (Postfix) with ESMTP id 4728537B406 for ; Thu, 25 Oct 2001 21:52:18 -0700 (PDT) Received: by dms-lcc-vck-m1.dms.usace.army.mil with Internet Mail Service (5.5.2653.19) id ; Thu, 25 Oct 2001 23:51:58 -0500 Message-ID: <06F2D681CAF4774DBDD5852190A0CC213EF968@POJMAIL02.poj.usace.army.mil> From: "Mishler, Barry A POJ" To: freebsd-net@FreeBSD.ORG Subject: Timeout on dns resolver functions Date: Thu, 25 Oct 2001 23:22:01 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C15DD5.C23E8920" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C15DD5.C23E8920 Content-Type: text/plain; charset="iso-8859-1" I'm sure this has been discussed before but I've been unable to find a proper solution... Is there a nice portable way to establish a timeout on the resolver routines? I let trafshow run for several hours when it caused a flood of 'File Table Full' syslog messages. It turns out that the trafshow code sets an alarm() before it calls gethostbyaddr and then it wraps the whole thing inside a setjmp block. When the reverse lookup takes too long, the gethostbyaddr is terminated ungracefully leaving a file descriptor open. After a while, this file descriptor leakage fills up the table. I've found that trafshow's addrtoname.c was lifted pretty much straight out of the tcpdump collection. The biggest difference is that tcpdump waits 20 seconds whereas trafshow defaults to a 2-second wait in order to keep things moving. So I can only assume that tcpdump would similarly fill up the FD table if given the chance. I don't know if this is relevant, but trafshow never leaked descriptors until I upgraded from some version of 4.0-STABLE to 4.1-RELEASE. I confirmed this on two machines. I never got around to tracking it down until recently. Sorry. So what's a portable program to do? How can this FD leakage be avoided? Thanks in advance, Barry -- Barry Mishler System/Network Manager Japan Engineer District U.S. Army Corps of Engineers ------_=_NextPart_001_01C15DD5.C23E8920 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Timeout on dns resolver functions

I'm sure this has been discussed before but I've been = unable to find a proper solution...

Is there a nice portable way to establish a timeout = on the resolver routines?

I let trafshow run for several hours when it caused a = flood of 'File Table Full' syslog messages.  It turns out that the = trafshow code sets an alarm() before it calls gethostbyaddr and then it = wraps the whole thing inside a setjmp block.  When the reverse = lookup takes too long, the gethostbyaddr is terminated ungracefully = leaving a file descriptor open.  After a while, this file = descriptor leakage fills up the table.

I've found that trafshow's addrtoname.c was lifted = pretty much straight out of the tcpdump collection.  The biggest = difference is that tcpdump waits 20 seconds whereas trafshow defaults = to a 2-second wait in order to keep things moving.  So I can only = assume that tcpdump would similarly fill up the FD table if given the = chance.

I don't know if this is relevant, but trafshow never = leaked descriptors until I upgraded from some version of 4.0-STABLE to = 4.1-RELEASE.  I confirmed this on two machines.  I never got = around to tracking it down until recently.  Sorry.

So what's a portable program to do?  How can = this FD leakage be avoided?

Thanks in advance,
Barry

--
Barry Mishler
System/Network Manager
Japan Engineer District
U.S. Army Corps of Engineers

------_=_NextPart_001_01C15DD5.C23E8920-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message