Re: Sockets left in TIME_WAIT

David Chappell (
Wed, 9 Oct 1996 09:26:54 -0400

Date: Wed, 9 Oct 1996 09:26:54 -0400
From: (David Chappell)
Message-Id: <>
In-Reply-To: Alan Yagoda/VGI <>
To: Alan Yagoda/VGI <>,
        fastcgi-developers <>
Subject: Re: Sockets left in TIME_WAIT

I had heard from a friend that this is actually a bug in the OS kernel, and that 
Sun has a patch for it.  What I heard was that Sun has something called a 
"Jumbo Patch" for Solaris 2.41 that fixes the problem.  The other thing I heard 
was that Solaris 2.5 came out and didn't have the patch automatically rolled 
into it.  I don't have any more details on it other than that.  If anyone finds 
out more, then let me know, since this is all hearsay until I get some 
confirmation from someone else about it.


On Oct 9,  7:13am, Alan Yagoda/VGI wrote:
> Subject: Sockets left in TIME_WAIT
> We are using a remote managed fastcgi application started with cgi-fcgi.   
> It appears that every time a request is issued from the OM Web Server to the 
> remote fastcgi application, the  socket descriptor used by the fastcgi 
> application is left in a TIME_WAIT state (using 'netstat -a' on Solaris to 
> descriptor state).   Normally setting sockopt() with SO_REUSEADDR on the 
> listen() socket descriptor alleviates this problem.   We are using a version 
> cgi-fcgi that sets SO_REUSEADDR but we are still seeing the connections being 
> left in TIME_WAIT until the OS cleans up.     We have gotten to the point 
> we can't connect to the fastcgi application because it can't allocate any more 
> descriptors.
> We had to reconfigure kernal paramteres  using 'ndd' to clean up open 
> descriptors more frequently.   I suspect that this is not the correct 
> but it has worked so far.    
> Has anyone seen this problem?    Any suggestions on how to close the 
> connections cleanly?
> Thanks.
> -Alan
> *************************************************************************
> Alan Yagoda    Phone:  610 669 1743
> Sr. Information Systems Engineer Fax: 610 669 1714
> The Vanguard Group   E-Mail:
>-- End of excerpt from Alan Yagoda/VGI