132

I run a particular program on linux which sometimes crashes. If you open it quickly after that, it listens on socket 49201 instead of 49200 as it did the first time. netstat reveals that 49200 is in a TIME_WAIT state.

Is there a program you can run to immediately force that socket move out of the TIME_WAIT state?

3

8 Answers 8

21

Actually there is a way to kill a connection - killcx. They claim it works in any state of the connection (which I have not verified). You need to know the interface where communication happens though, it seems to assume eth0 by default.

UPDATE: another solution is cutter which comes in some linux distros' repositories.

3
  • Killcx just doesn't work for me. Cutter requires a firewall to interact with.
    – Owl
    Sep 8, 2021 at 0:53
  • Any command which is available in the Redhat 7 or above to achive this ?
    – nitinr708
    Apr 22, 2022 at 19:19
  • @nitinr708 nothing out of the box afaik :/ you need to install from the upstream projects. Apr 23, 2022 at 18:54
166
/etc/init.d/networking restart

Let me elaborate. Transmission Control Protocol (TCP) is designed to be a bidirectional, ordered, and reliable data transmission protocol between two end points (programs). In this context, the term reliable means that it will retransmit the packets if it gets lost in the middle. TCP guarantees the reliability by sending back Acknowledgment (ACK) packets back for a single or a range of packets received from the peer.

This goes same for the control signals such as termination request/response. RFC 793 defines the TIME-WAIT state to be as follows:

TIME-WAIT - represents waiting for enough time to pass to be sure the remote TCP received the acknowledgment of its connection termination request.

See the following TCP state diagram: alt text

TCP is a bidirectional communication protocol, so when the connection is established, there is not a difference between the client and the server. Also, either one can call quits, and both peers needs to agree on closing to fully close an established TCP connection.

Let's call the first one to call the quits as the active closer, and the other peer the passive closer. When the active closer sends FIN, the state goes to FIN-WAIT-1. Then it receives an ACK for the sent FIN and the state goes to FIN-WAIT-2. Once it receives FIN also from the passive closer, the active closer sends the ACK to the FIN and the state goes to TIME-WAIT. In case the passive closer did not received the ACK to the second FIN, it will retransmit the FIN packet.

RFC 793 sets the TIME-OUT to be twice the Maximum Segment Lifetime, or 2MSL. Since MSL, the maximum time a packet can wander around Internet, is set to 2 minutes, 2MSL is 4 minutes. Since there is no ACK to an ACK, the active closer can't do anything but to wait 4 minutes if it adheres to the TCP/IP protocol correctly, just in case the passive sender has not received the ACK to its FIN (theoretically).

In reality, missing packets are probably rare, and very rare if it's all happening within the LAN or within a single machine.

To answer the question verbatim, How to forcibly close a socket in TIME_WAIT?, I will still stick to my original answer:

/etc/init.d/networking restart

Practically speaking, I would program it so it ignores TIME-WAIT state using SO_REUSEADDR option as WMR mentioned. What exactly does SO_REUSEADDR do?

This socket option tells the kernel that even if this port is busy (in
the TIME_WAIT state), go ahead and reuse it anyway. If it is busy, but with another state, you will still get an address already in use error. It is useful if your server has been shut down, and then restarted right away while sockets are still active on its port. You should be aware that if any unexpected data comes in, it may confuse your server, but while this is possible, it is not likely.

5
  • 12
    Great answer, but not the correct answer to his question. Restarting the networking would work, but then so would rebooting, so this can't be right. Aug 6, 2009 at 17:03
  • 4
    @Chris Huang-Leaver, the question is "Is there a program you can run to immediately force that socket move out of the TIME_WAIT state?" if rebooting could be considered running a program, then it too would be a right answer. Why do you think this can't be right? Aug 6, 2009 at 17:59
  • 9
    WMR has the most useful answer (which is what I do when I run into this kind of issue). Restarting the network is too drastic to be solution, and could take longer than simply waiting for the timeout.The correct answer to his question is 'No', but SO won't let you type two letter answers :-) Sep 2, 2009 at 11:23
  • 7
    oh okay, next time some process hangs on SIGTERM I'll just smash my computer instead of fixing it.
    – Longpoke
    May 13, 2010 at 16:13
  • 1
    The generalization of this is "restart network services". The specific location /etc/init.d/networking is platform-specific (Debian?) so the precise command line will be different (sometimes rather radically so) for other systems. I agree with other commenters that this seems like severe overkill and obviously disruptive for any unrelated network services.
    – tripleee
    Jun 26, 2019 at 8:22
54

I don't know if you have the source code of that particular program you're running, but if so you could just set SO_REUSEADDR via setsockopt(2) which allows you to bind on the same local address even if the socket is in TIME_WAIT state (unless that socket is actively listening, see socket(7)).

For more information on the TIME_WAIT state see the Unix socket FAQ.

5
  • but i did not get the already bound error. when i execute the program again it listens in post(123456) also i can see a that the system is showing TIME_WAIT for that port but still i can connect. why? Sep 27, 2010 at 8:26
  • 3
    Even with SO_REUSEADDR, it is still possible to get the "Address already in use" error. For details, refer to hea-www.harvard.edu/~fine/Tech/addrinuse.html. Jun 27, 2013 at 2:16
  • @WMR SO_REUSEADDR does not "close" a socket. It merely enables you to reuse those that are already opened. So the question is still "How to forcibly close a socket in TIME_WAIT?"
    – Pacerier
    Jan 23, 2016 at 4:15
  • This is the correct answer, but the question was not totally correct. At least solved my problem nicely (not like restart the whole network breaking all other connections as well).
    – V-Mark
    Dec 29, 2018 at 11:08
  • SO_REUSEADDR will let bind() proceed; but if you then want to listen to that socket, listen() will return EADDRINUSE all the same. In other words, this answer may help client software using ephemeral ports, but doesn't solve the issue for server software.
    – Will
    Jun 16, 2019 at 4:06
35

As far as I know there is no way to forcibly close the socket outside of writing a better signal handler into your program, but there is a /proc file which controls how long the timeout takes. The file is

/proc/sys/net/ipv4/tcp_tw_recycle

and you can set the timeout to 1 second by doing this:

echo 1 > /proc/sys/net/ipv4/tcp_tw_recycle 

However, this page contains a warning about possible reliability issues when setting this variable.

There is also a related file

/proc/sys/net/ipv4/tcp_tw_reuse

which controls whether TIME_WAIT sockets can be reused (presumably without any timeout).

Incidentally, the kernel documentation warns you not to change either of these values without 'advice/requests of technical experts'. Which I am not.

The program must have been written to attempt a binding to port 49200 and then increment by 1 if the port is already in use. Therefore, if you have control of the source code, you could change this behaviour to wait a few seconds and try again on the same port, instead of incrementing.

4
  • think the second two examples should be s/rw/tw/ I'd edit, but lack enough rep.
    – blueshift
    Oct 6, 2009 at 3:26
  • 1
    Taken from kernel documentation: Caution. Both tcp_tw_recycle and tcp_tw_reuse can cause problems. You should not enable either without understanding network topology in between node(s) which are using or used by the node where the parameter is enabled. Connections which go via nodes that are aware of TCP connection states, such as firewall, NAT or load balancer may start dropping frames because of the setting. The problem will become visible when there is large enough number of connections.
    – jfarrell
    Feb 22, 2010 at 18:54
  • Setting it to 1 works for future connections, but what about those current ones that are already opened?
    – Pacerier
    Jan 23, 2016 at 4:16
  • anybody knows what was beyond the (now broken) bram.creative4vision.nl/debian/timewait.html link ?
    – sylvainulg
    Aug 23, 2021 at 10:01
5

Yes, there is. You can use ss to immediately destroy all sockets that are in TIME-WAIT state like this:

ss state time-wait sport = 49200 -K

After that, restarting your listener should succeed instead of its bind call failing due to Address already in use.

NB: This command requires super-user privileges.


Alternatively, if you are able to modify your program you can simply set SO_REUSEADDR before binding the socket such that the bind still succeeds despite having stale connections being in TIME-WAIT state.

1
  • 2
    Indeed this looks to me to be the only correct answer to OP's question: can be done after the fact rather than changing beforehand various settings (of course SO_REUSEADDR should always be used for a server, but if it wasn't done when initially run...), and really removes the kernel's known entry. Any answer telling packets must be sent don't change anything on the local network's stack state when it's in TIME_WAIT state. Of course the ability to remove a socket entry with ss was probably not available when the question was asked.
    – A.B
    Feb 19, 2023 at 15:51
3

Another option is to use the SO_LINGER option with a timeout of 0. This way, when you close the socket is forcibly closed, sending a RST instead of going into the FIN/ACK closing behavior. This will avoid the TIME_WAIT state, and may be more appropriate for some uses.

4
  • 3
    It also loses any outbound data that is still in transit, and may cause an error at the other end. Not recommended.
    – user207421
    Mar 31, 2011 at 9:46
  • @EJP Failing early is almost always the right call. Networking isn't reliable, and fighting that will slow things down. A crashed app can't assume that any data made it out safely.
    – Tobu
    Dec 9, 2014 at 2:06
  • 2
    Actually, I'd recommend this any day when the other endpoint is a buggy, embedded industrial bus gateway that implements its own application-layer reliable transport over TCP, where said transport prevents the connection from ever closing unless it receives RST and thus fills up the connection limit on that gateway. There. I gave you a very specific and very real example that, sadly, requires resorting to hacks like this.
    – andyn
    May 28, 2015 at 18:33
  • @Tobu Networking isn't reliable, but TCP tries to be, and making that worse doesn't constitute making anything better, and letting TCP do its job doesn't constitute 'fighting' anything.
    – user207421
    Mar 22, 2018 at 2:45
3

An alternative solution would be to have some reliable proxy or port forwarding software that listens on port 49200, then forward the connection on to one of several instances of your less reliable program using different ports... HAPROXY springs to mind.

Incidentally the port your connecting on is quite high. You could try using an unused one just above the 0-1024 range. Your system is less likely to use a lower port number as an ephemeral port.

0

TIME_WAIT is most common issue in socket programming client server architecture. Wait for few seconds trying periodically is the best solution for it. For real time applications they need server must get up immediately There is SO_REUSEADDR option for them.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .