You may want to edit include/net/tcp.h and tune the TCP timeout values to
suit your need and adjust timeout to a lower value from there.
We've been running various services that require such tuning especially on
heavily loaded servers to obtain optimum performance.
Rgds,
-Lim Fung
On Mon, 20 Apr 1998, Gerhard Kutzelnigg wrote:
| Date: Mon, 20 Apr 1998 14:22:04 +0100
| From: Gerhard Kutzelnigg <gerhard@pre.de>
| To: "linux-kernel@vger.rutgers.edu" <linux-kernel@vger.rutgers.edu>
| Subject: help on fin_wait
|
| Hi,
|
| Can anybody help me with this problem that has to do with connection
| handling?
|
| Well, actually I just want to force an hanging TCP connection to shut
| down.
| But when a socket is in the FIN_WAIT1/2 state, sometimes I have to wait
| up to 15 minutes for the socket to be closed by the system. This is very
|
| annoying if I want to restart my server daemon, because I can't bind to
| the port until all sockets are closed correctly.
|
| There is no problem with the server, but sometimes the clients just cut
| the connection without sending anything. So if I need to restart the
| server (completely, in this case bind () necessary), bind () just fails
| since not all sockets are closed, but I know that there can't /
| shouldn't be any existing sockets, not even in any wait state, because
| the server is startet manually again. Unfortunately I don't have any
| handles to theses sockets any more if the server crashes before.
|
| Since the kernel closes such connections after a 15 minute timeout or
| so,
| I just wondered how I could force to close connections in these
| waitstates on startup of my server or whenever.
|
| I don't want to shutdown eth0, so is there maybe a tool, that can kill a
| connection like killing a process/task?
|
| cu gerry
|
| Gerhard Kutzelnigg
| gerhard@pre.de
|
|
|
|
|
|
| -
| To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
| the body of a message to majordomo@vger.rutgers.edu
|
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu