From owner-freebsd-stable Tue Nov 9 23:28:33 1999
Delivered-To: freebsd-stable@freebsd.org
Received: from smtp10.atl.mindspring.net (smtp10.atl.mindspring.net [207.69.200.246])
by hub.freebsd.org (Postfix) with ESMTP id 89DD214A00
for <freebsd-stable@freebsd.org>; Tue, 9 Nov 1999 23:28:29 -0800 (PST)
(envelope-from dex@wankers.net)
Received: from wankers.net (user-38lcilb.dialup.mindspring.com [209.86.74.171])
by smtp10.atl.mindspring.net (8.8.5/8.8.5) with ESMTP id CAA18945
for <freebsd-stable@freebsd.org>; Wed, 10 Nov 1999 02:28:27 -0500 (EST)
Received: from localhost (dex@localhost.mindspring.com [127.0.0.1])
by wankers.net (8.9.3/8.9.3) with ESMTP id CAA22823
for <freebsd-stable@freebsd.org>; Wed, 10 Nov 1999 02:28:20 -0500 (EST)
(envelope-from dex@wankers.net)
Date: Wed, 10 Nov 1999 02:28:20 -0500 (EST)
From: Taz <dex@mindspring.com>
X-Sender: dex@localhost.mindspring.com
To: freebsd-stable@freebsd.org
Subject: a CLOSE_WAIT fiasco
Message-ID: <Pine.BSF.4.10.9911100219560.1649-100000@localhost.mindspring.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-stable@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG
This is basically an FYI. I have 2 fetchmail processes that have been
running on a 3.3-STABLE box for a week. Suddenly, a few hours ago, I ran
out of available file descriptors. Upon investigation, fetchmail and
sendmail had been uncooperative with each other due to this issue. Oddly
enough, the instance of fetchmail with the problem was the one that
delivers FAR less mail.
a netstat -an showed over 800 connections in CLOSE_WAIT. After killing
sendmail, several of these gradually expired, but I still maintained a
constant 800+ CLOSE_WAIT state connections upon restarting it. I finally
tracked down the issue when I realized that something was STILL wrong, and
ran an fstat. fetchmail had a collection of fd's corresponding to the
connections stuck in CLOSE_WAIT. upon killing the process, exactly 800
connections left CLOSE_WAIT.
The moral of this story is: if you run out of fd's and you run fetchmail
with a local MTA, do an fstat and look for a fetchmail process with
several lines. More than 20 stream connections means it's having a
problem, and killing it will resolve the issue. No need to wreck your
uptime for a few hundred hung connections.
-J.
--
opinions? cat creative_criticism >/dev/ponder
cat flames >/dev/null
-- J.D. Mischo -- SuperTaz -- DexNation Holodream -- dex@wankers.net --
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-stable" in the body of the message