Server Fault is a question and answer site for system and network administrators. 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

When you start a program to listen on a TCP socket then kill the program, sometimes (but not always) you get an error like "address already in use" when you try to listen on the socket again for the next few mins. The proc is killed with ctrl-c. I use linux.

I think this has something to do with a TCP connection being stuck in the CLOSE_WAIT state, but am not 100% sure. Why exactly do I get the "address already in use" error?

Also, why does this only sometimes happen?

share|improve this question
Which process is it that you're killing? Are you killing it gracefully or with a -9? – vmfarms Aug 16 '10 at 1:33
Is there an actual question? – GregD Aug 16 '10 at 1:33
Hi, welcome to! Unfortunately, your question is rather unclear. Please include some more detail (OS, application), and make it into an actual question. Otherwise your question will probably be closed. – sleske Aug 16 '10 at 1:41

There is a feature in IP stacks that prevents a process to reopen a socket in listening mode too fast (that's a 2 minutes wait I think). Most of today programs remove this feature when they create a socket by using the SO_REUSEADDR flag when they create a socket. Maybe your program doesn't using this flag?

share|improve this answer
it doesn't, but I believe I have run into this problem before using the flag after being told it wouldn't happen again. – Jan Somers Aug 16 '10 at 1:46

Try using netstat to see the state of the port or lsof -i: after you kill it to see what programs are still using the port if any.

share|improve this answer

In which language are you writing ?

If you are writing in C, propably you need to check setsockopt() or better, select().

There are the functions to make the socket reusable , as being said.

share|improve this answer

Your Answer


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