If I kill a program that is listening on a TCP port, it takes up to several minutes until the port is reclaimed by the system and usable again. I've seen several Q/A mentioning this phenomenon, but without an explanation. Why does that happen, why doesn't the system reclaim the port right away? Does it also happen on another systems, such as Windows or Mac?

1 Answer 1


The idea behind this is to ensure you don't receive packets targeted for the previous program listening on that port. This TIME_WAIT state is defined in RFC793 as two times the maximum segment lifetime.

I don't know about other Operating Systems but I assume that all of these have some kind of similar behavior.

A workaround for this problem is to set SO_REUSEADDR on the socket which should ignore the TIME_WAIT state.

  • 3
    Checking my trusty TCP state diagram, I can see that the TIME_WAIT is the last state of a socket and generally persists for 2MSL - which is twice the maximum segment lifetime. The spec (RFC793) states this as 2 minutes, giving 4 minutes in total. This allows enough time for any requests and replies still "in flight" to be processed and land up at the right program - or to be discarded if the socket is in TIME_WAIT.
    – Faelkle
    Commented Mar 18, 2013 at 11:38
  • I can confirm that this happens in Windows too. Commented Mar 30, 2013 at 10:03
  • Additional Dig on this subject hea-www.harvard.edu/~fine/Tech/addrinuse.html Commented Aug 13, 2020 at 9:37

You must log in to answer this question.

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