Re: Sockets left in TIME_WAIT

David Chappell (chappell@bedford.progress.com)
Wed, 9 Oct 1996 09:26:54 -0400 

Date: Wed, 9 Oct 1996 09:26:54 -0400
From: chappell@bedford.progress.com (David Chappell)
Message-Id: <961009091841.ZM11902@pcchappell.bedford.progress.com>
In-Reply-To: Alan Yagoda/VGI <Alan_Yagoda@vanguard.com>
To: Alan Yagoda/VGI <Alan_Yagoda@vanguard.com>,
        fastcgi-developers <fastcgi-developers@openmarket.com>
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.

Dave

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 
view 
> descriptor state).   Normally setting sockopt() with SO_REUSEADDR on the 
> listen() socket descriptor alleviates this problem.   We are using a version 
of 
> 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 
where 
> 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 
solution, 
> 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: Alan_Yagoda@vanguard.com
>  
>-- End of excerpt from Alan Yagoda/VGI