Date: Wed, 10 Nov 1999 02:28:20 -0500 (EST) From: Taz <dex@mindspring.com> To: freebsd-stable@freebsd.org Subject: a CLOSE_WAIT fiasco Message-ID: <Pine.BSF.4.10.9911100219560.1649-100000@localhost.mindspring.com>
next in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.10.9911100219560.1649-100000>