You're kind of asking the wrong question here. It isn't really possible to simply "close a port" from outside the application that opened the socket listening on it. The only way to do this is to completely kill the process that owns the port. Then, in about a minute or two, the port will become available again for use. Here's what's going on (if you don't care, skip to the end where I show you how to kill the process owning a particular port):
Ports are resources allocated by the OS to different processes. This is similar to asking the OS for a file pointer. However, unlike file pointers, only ONE process at a time may own a port. Through the BSD socket interface, processes can make a request to listen on a port, which the OS will then grant. The OS will also make sure no other process gets the same port. At any point, the process can release the port by closing the socket. The OS will then reclaim the port. Alternatively, if the process ends without releasing the port, the OS will eventually reclaim the port (though it won't happen immediately: it'll take a few minutes).
Now, what you want to do (simply close the port from the command-line), isn't possible for two reasons. First, if it were possible, it would mean one process could simply steal away another process's resource (the port). This would be bad policy, unless restricted to privileged processes. The second reason is it is unclear what would happen to the process that owned the port if we let it continue running. The process's code is written assuming that it owns this resource. If we simply took it away, it would end up crashing on it's own, so OS's don't let you do this, even if you're a privileged process. Instead, you must simply kill them.
Anyway, here's how to kill a process that owns a particular port:
sudo netstat -ap | grep :<port_number>
That will output the line corresponding to the process holding port , for example:
tcp 0 0 *:8000 *:* LISTEN 4683/procHoldingPort
In this case, procHoldingPort is the name of the process that opened the port, 4683 is its pid, and 8000 (note that it is TCP) is the port number it holds.
Then, look in the last column, you'll see /. Then execute this:
kill <pid>
If that doesn't work (you can check by re-running the netstat command). Do this:
kill -9 <pid>
In general, it's better to avoid sending SIGKILL if you can. This is why I tell you to try kill
before kill -9
. Just using kill
sends the gentler SIGTERM.
Like I said, it will still take a few minutes for the port to re-open if you do this. I don't know a way to speed this up. If someone else does, I'd love to hear it.
10A lot of responders missed the point of this question. It is nonsense to declare that only the application that owns the port can disconnect it. I can disconnect it by walking up to the box and pulling the ethernet cable out of the socket, or by killing the application at the other end of the connection! The application must be written to handle this. So --- how do you test to be sure the application is written properly without requiring physical intervention and/or control of the other computer? – Dale Wilson – 2014-09-22T19:39:34.343
"... there is no control possible from outside." That's an important remark, that's guided me to the next question, how can i be the part of the process from the outside? GDB. – Dankó Dávid – 2018-05-17T12:57:26.763
@JürgenStrobel There is indeed control possible from outside - both tcpkill and ss can do exactly what is asked for. Because opened ports do not truly belong to a process; they are kernel resources, with some rights assigned to a process, but still existing only at the kernel's pleasure. – Tom Anderson – 2019-08-07T15:19:49.097
@tom-anderson DaleW: tcpkill is a firewalling tool, and I did mention this option. You can prevent traffic to a port, which is different than closing a port (socket). – Jürgen Strobel – 2019-08-10T18:32:05.950
5No, opened ports belong to the process which opened them, there is no control possible from outside. Which is a good thing, or all applications would have to anticipate their open ports (and files) being messed with. However, you can block traffic to a port by firewalling (iptables), but that will not close and give up the port for other use. – Jürgen Strobel – 2011-10-06T00:26:20.053