Sockets stuck in FIN_WAIT_1

Robert Blayzor rblayzor.bulk at inoc.net
Fri May 30 19:30:50 UTC 2008


On May 30, 2008, at 3:17 PM, Doug Barton wrote:
> I'm not sure why, but I sense hostility on your part. I'm not sure  
> why, since that is an odd reaction to someone who is trying to help  
> you. If I'm wrong about that, never mind.

I'm not being hostile, geez. ;)  I simply asked "why not"?  Plenty of  
people do it, and with good reason.  It's always been effective, if  
this is some sort of an IPFW load issue, then surely I concede your  
point to use an external firewall, which I can do with basic external  
router ACL's.

> A basic rule of system administration is to have a good reason for  
> everything you do. If you have some kind of need for a firewall on  
> your web server, that's fine. Personally I prefer not to run  
> firewalls on application servers, but TIMTOWTDI.

Of course, but every situation is different.  In this case, an  
external firewall is not available and the application doesn't really  
require it, so simple IPFW rules are sufficient.

> The real crux of my question (which you did not answer) is, does the  
> problem go away if you take IPFW completely out of the equation? If  
> the answer to that is yes, it greatly narrows the focus of the  
> investigation.

No, turning IPFW off does not make the problem go away.  I originally  
thought of this when the issue came up.  I've tried with and without  
both the http accept filter and IPFW.

> I think that the theories that have been proposed by others that the  
> FIN_WAITs are a symptom of a problem in the clients is not only  
> possible, it's likely. I'm just not sure it's the complete story.


I'm thinking it probably is bad client behavior.  I'm leaning toward  
all of the freshclam clients not handling a network error correctly.   
It's quite possible when something in the connection fouls up the  
client, it just behaves badly.  I don't know much about how freshclam  
uses sockets, I'm trying to figure that out now. (if they use some  
native code, http library, etc).  It not might even be that at all,  
but it's a good starting point.

The other half of the story however is if it's that easy to hose up  
TCP sockets on a server, that's a bigger problem IMHO. :-/

-- 
Robert Blayzor, BOFH
INOC, LLC
rblayzor at inoc.net
http://www.inoc.net/~rblayzor/





More information about the freebsd-stable mailing list