Fw: FIN_WAIT_2

[Tek Bahadur Limbu]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sun, 25 Feb 2007 05:23:20 -0500
"Grant Peel" <gpeel at thenetnow.com> wrote:

>  my problem is that so many of my vm-pop3d processes get in that
> state that semi-frequently, we get locked out of downloading email.
> 
>  I kill all the vm-pop3d processes then we have to wait for all the
>  FIN_WAIT_2 to die befor i can restart the vm-pop3d process.
> 
>  If I try to start vm-pop3d before all the FIN_WAIT_2 sockets die, I
> get a 'Can't bind to port" error.
> 
>  When I do the lsof thing it shows no files or processes connected to
> that port, or socket.

Hi Grant,

I also seem to getting the same problem as yours except that my server
is a Squid proxy running on FreeBSD 6.0. Using 
 
netstat -an | grep tcp | awk '{print $6}' | sort | uniq -c

gives the following:

23 CLOSE_WAIT
   9 CLOSING
3955 ESTABLISHED
3342 FIN_WAIT_1
2604 FIN_WAIT_2
  49 LAST_ACK
   15 LISTEN
  16 SYN_SENT
  148 TIME_WAIT

Then I start to get the following in my squid logs:

2007/02/25 17:10:37| comm_open: socket failure: (55) No buffer space
available 

I tried by setting the variable net.inet.ip.fw.dyn_keepalive=0 but it
didn't help that much.

It is only after I stop Squid for about 20-30 seconds and restart it,
will the number of connections start to drop. 

I think that the best way to tackle this problem is by using a firewall
to rate-limit the number of connections per IP per time.


> 
>  -Grant
> 
> > ----- Original Message ----- 
> > From: "Christian Walther" <cptsalek at gmail.com>
> > To: "Grant Peel" <gpeel at thenetnow.com>
> > Cc: <freebsd-questions at freebsd.org>
> > Sent: Saturday, February 24, 2007 9:53 AM
> > Subject: Re: FIN_WAIT_2
> >
> >
> >> On 24/02/07, Grant Peel <gpeel at thenetnow.com> wrote:
> >>> Hi all,
> >>>
> >>> Just wondering if anyone has found / knows of a way to kill
> >>> sockets that are stuck in FIN_WIAT_2 state - without rebooting
> >>> the server.
> >>>
> >>> When I kill the processes (in this case the pop3 server) that
> >>> allows the connection, it still takes about 3 hours for the
> >>> socket to time out and die.
> >>
> >> What is your problem with sockets being in this state? Normaly they
> >> don't consume any resources that would lead to performance
> >> problems. As you say, they die eventually.
> >> Sockets in this state are no problem, it's just that the client
> >> failed to sent the last ACK to the server, which would finally
> >> close the communication.
> >>
> >>
> > 
> 
> _______________________________________________
> freebsd-questions at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-questions
> To unsubscribe, send any mail to
> "freebsd-questions-unsubscribe at freebsd.org"
> 


- -- 


With best regards and good wishes,

Yours sincerely,

Tek Bahadur Limbu

(TAG/TDG Group)
Jwl Systems Department

Worldlink Communications Pvt. Ltd.

Jawalakhel, Nepal

http://www.wlink.com.np
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (FreeBSD)

iD8DBQFF4ZTAVrOl+eVhOvYRAmWsAJ48mBKXDDYPIB+9Whgq2kl51JvIvACdHvR/
T73CpykghiHwlVZ4yCKxJE0=
=UDbN
-----END PGP SIGNATURE-----