Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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?

share|improve this question
up vote 25 down vote accepted

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.

share|improve this answer
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 Mar 18 '13 at 11:38
I can confirm that this happens in Windows too. – Thomas Bratt Mar 30 '13 at 10:03

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.