67

Pretty simple, I know that this has happened to me before. Couldn't find a good answer on AU.

I was running an ssh session with ports bound:

ssh -L 3000:<server_name>:22

I just lost my connection. When I try to reconnect using the same command, I get the following error:

bind: Address already in use
channel_setup_fwd_listener: cannot listen to port: 3000

How do I reset ssh on my machine to allow the port to be bound again? Resetting the local machine works.

0
92

Couldn't you just kill whatever is using that port?

 lsof -ti:5901 | xargs kill -9

lsof -ti:5901 to find whatever is using port 5901.

Pass the whole thing to kill -9 to kill whatever was using port 5901.

Replace with the port you want to open up again.

7
  • Yes, you could change the port number to whatever port is being blocked. I am going to mark this as the answer. – kbuilds Sep 15 '15 at 15:06
  • If you are cautious and/or forgetful like me, you may wish to run lsof on its own and find out what the process is before killing it. lsof -ti:5901 will return a process number, which you then pass to kill -9 – octern Dec 7 '16 at 4:54
  • 3
    what if nothing is using port 5901 (or whatever local port you are specifying)? – Michael Dec 24 '16 at 4:31
  • 1
    I see no processes even with sudo. – Joseph Garvin Dec 26 '18 at 20:15
  • 4
    There is no reason to kill -9 unless the program is completely unresponsive. Killing a process with signal #9 (SIGKILL) terminates it immediately without giving the process a chance to flush buffers, close filehandles and sockets, remove temporary files, etc., all of which the process can do if you use kill (defaults to SIGTERM), followed by kill -1 (SIGHUP; hangup) and kill -2 (SIGINT; what Ctrl+C sends) if that doesn't work, and finally kill -9 if nothing else works. – TheDudeAbides Oct 10 '19 at 1:59
13

I suppose you have still something connected to local port 3000.

You can find it with

netstat -tulpn | grep 3000 

and then dispose of it. For example in my machine:

[:~] % netstat -tulpn | grep 5900
(Not all processes could be identified, non-owned process info
 will not be shown, you would have to be root to see it all.)
tcp        0      0 0.0.0.0:5900            0.0.0.0:*               LISTEN      2547/vino-server
tcp6       0      0 :::5900                 :::*                    LISTEN      2547/vino-server

correctly identifies the process waiting and connected on port 5900 (vnc server).

Another useful command is

fuser 3000/tcp 

...all of them may need to be run with sudo if you do not own the process which is opening the port.

2
  • Thanks for the answer. I will have to dig into it to see if I can recreate the issue. The only possible application that could have been listening on port 3000 was the old ssh session that was disconnected. My user owned the process, so I assumed I would be able to run a killall ssh and have it die. Guess that's not the case – kbuilds Apr 15 '14 at 0:13
  • Thanks for the reminder to use sudo - that's what I was missing. – ACV Feb 11 '16 at 20:13
5

I was able to recreate and fix it by doing the following:

  • Open up something that will list your processes (ps -ae)
  • Kill the process called sh (kill <proc_number>)

Then reopen the ssh connection

Alternatively, I have had success with:

killall ssh

In the terminal on the local machine

2

one more contender: ss

it can be used like this: ss -ltp | grep 3000 to find the program listening on port 3000

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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