Manually closing a port from commandline

Question

I want to close an open port which is in listening mode between my client and server application.

Is there any manual command line option in Linux to close a port?

NOTE: I came to know that "only the application which owns the connected socket should close it, which will happen when the application terminates."

I don't understand why it is only possible by the application which opens it ... But I'm still eager to know if there is any other way to do it.

No, 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, Oct 06 '11 at 00:26
A 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, Sep 22 '14 at 19:39
"... 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, May 17 '18 at 12:57
@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, Aug 07 '19 at 15:19
@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, Aug 10 '19 at 18:32

score 178 · Answer 1 · edited Aug 09 '19 at 09:08

178

I had same problem, the process must keep alive but the socket must close. Closing a socket in a running process is not impossible but difficult:

locate the process :
```
netstat -np
```
You get a source/destination ip:port portstate pid/processname map
locate the the socket's file descriptor in the process
```
lsof -np $pid
```
You get a list: process name, pid, user,fileDescriptor, ... a connection string.

Locate the matching fileDescriptor number for the connection. It'll be something like "97u" which means "97".
Now connect the process:
```
gdb -p $pid
```

Now close the socket:

call close($fileDescriptor) //does not need ; at end.

example:

call close(97)

Then detach gdb:

quit

And the socket is closed.

edited Aug 09 '19 at 09:08

Albin

10,559

answered Nov 01 '13 at 01:43

Dankó Dávid

1,929

1

sudo lsof -np $pid gives me about 200 lines and I'm confused about how to find desired FD. In my case process is a Chrome tab and i'm trying to close opened websockets... – SET Jun 10 '14 at 09:25
2

A row typically looks like: firefox 14812 szupervigyor 97u IPv4 32814564 0t0 TCP 192.168.2.4:40385->173.194.39.65:https (ESTABLISHED)
as: process_name pid user fd[opened_for] protocol device inode protocol_data_toString
– Dankó Dávid Jun 11 '14 at 23:32
2

A row typically looks like: firefox 14812 szupervigyor 97u IPv4 32814564 0t0 TCP 192.168.2.4:40385->173.194.39.65:https (ESTABLISHED) as: process_name pid user fd[opened_for] protocol device inode protocol_data_toString

You need to know the remote ip address and find on the last col. In my example the 97 is the FileDescriptor. Searching is difficult if you opened multiple connection to the target host.

Dankó Dávid

Jun 11 '14 at 23:38

12

this is a brilliant solution – marcorossi Jan 22 '15 at 12:55

<slowclap.gif> - this is truly a life saver. – mik Jan 25 '16 at 19:44

10

If you want to simulate the socket being closed by the remote end (e.g. the peer exiting) it's better to use shutdown: call shutdown($fileDescriptor, 0). – ecatmur Apr 22 '16 at 10:19

Amazing, exactly what I needed. – 0atman May 20 '16 at 12:09

1

Never thought of this. My redis server was not accepting any connections. But I need to keep it alive. This helped me solve the problem. life saver – Shiplu Mokaddim Sep 15 '16 at 10:33

I wonder why it's so twisted in Linux. In Windows I can just launch Process Explorer (download from MS website), see a list of handles per process, and close them one by one using the mouse. Using gdb even pauses the program which is a pita because of timeouts etc. – Mark Jeronimus Dec 15 '17 at 09:12

I have a node process running with a very long timeout (~5hrs) and has a few connections open that will eventually fail so I tried calling both shutdown and close on each of these sockets but the process continued to be blocked. I can confirm from lsof output that these sockets are no longer there. Is there something else that I can do instead of waiting for 5hrs for it to timeout normally? – haridsv May 16 '18 at 07:27

Well i don't want to be a troll, but in unixes the /proc is the native process explorer in the system. However we can construct a really dummy command to close an fd of a process:
#!/bin/bash echo -e "call close($2)\ndetach\nquit\n" | gdb -p $1 > /dev/null 2>&1 close-proc-fd $pid $fd

that you can built into a backend of the application. However this solution - especially if you start gatling this as a command - is an overkill solution.

– Dankó Dávid May 17 '18 at 12:30

"Using gdb even pauses the program" yes, sadly it does anyway (https://stackoverflow.com/questions/9746018/gdb-attach-to-a-process-without-stop) but you can continue (cont) the execution right after the attach. – Dankó Dávid May 17 '18 at 12:36

but how to send msg in gdb, send(int sockfd, const void *buf, size_t len, int flags) e.g. want to send("hello") to other end. – zhuguowei Feb 20 '19 at 14:30

Great Solution :) @SET , You can use lsof -i @<ipaddress> to list only sockets which are started on that particular IP. – Prasad Bonthu May 07 '19 at 15:38

score 85 · Answer 2 · edited Nov 10 '17 at 13:37

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.

@smehmood - Thanks for the detailed explanation .. A small doubt .. How does the kernel reclaim a open port by an abruptly killed process ?? .. the solution u provided seems to be killing the process holding the port ... — , Apr 06 '10 at 04:17
@codingfreak The kernel knows the process is gone. It knows it can reclaim the port. There are actually rules on the timing of closing the port, to make sure there aren't any stray packets floating on the 'net. How does it know it has these resources? that's what the kernel does, keeps track of things. — Rich Homolka, Nov 01 '13 at 02:05
Until someone posts something sensible like unix.tools.port.close(<my port number>) I would use init 6. — Snowcrash, Feb 10 '17 at 20:57
This is an excellent answer to a different question. This question is about attaching a debugger and changing a running program to cause that program to call a function on a file descriptor. — Arthur Ulfeldt, Oct 01 '19 at 21:14
Great answer to the wrong question. I don't understand all the upvotes. — tink, Jan 28 '21 at 17:07
This answer is no longer correct, please downvote it. In 2010, linux did not have a way to close arbitrary ports from the command line. But that ability was added to the kernel many years ago, and the ss command line tool has exposed it since 2016, so it should now be available pretty much everywhere. — andrew.n, Sep 11 '21 at 02:05

score 26 · Answer 3 · edited Feb 05 '14 at 13:58

26

Fuser can also be used

fuser -k -n *protocol portno*

Here protocol is tcp/udp and portno is the number you wish to close. E.g.

fuser -k -n tcp 37

More info at fuser man page

edited Feb 05 '14 at 13:58

Willian Soares

115

answered Feb 13 '12 at 08:44

RedBaron

369

Just killing owning process didn't work for me, but fuser did. Thx! – webwurst May 13 '13 at 10:06
I got mixed results with it, even after using fuser, I got "socket already in use" when trying to reuse the port from killed app even doing so as root. On the other hand, the time to free the socket seemed to be shorter then before, so thanks anyway. – Jan Vlcinsky Apr 14 '14 at 08:16
@JanVlcinsky Maybe there is a "guardian" process which restarts the killed process moments after fuser is run? – RedBaron Apr 15 '14 at 05:12
@RedBaron: according to comment http://superuser.com/a/415236/153413 my problem originates in poorly written application, which does not clean up/close the socket under termination. So fuser finds the process using the port and kills it, but does not resolve the fact, that the socket is not closed. 60 seconds and kernel does it for me. – Jan Vlcinsky Apr 15 '14 at 16:25

score 15 · Answer 4 · answered Aug 07 '19 at 15:17

15

You can close a listening socket using ss:

sudo ss --kill state listening src :1234

Where 1234 is your port number.

ss is part of the iproute2 package, so there is a strong change it is already installed on a modern Linux.

I learned about this from an answer to a related question.

answered Aug 07 '19 at 15:17

Tom Anderson

1,773

1

Yup, this is the best answer. Internally, ss is sending a SOCK_DESTROY request to the kernel over the netlink interface. – andrew.n Sep 10 '21 at 16:35

score 7 · Answer 5 · edited Nov 15 '13 at 14:29

7

You could alternatively use iptables:

iptables -I INPUT -p tcp --dport 80 -j DROP

It basically accomplishes what you want. This will drop all TCP traffic to port 80.

edited Nov 15 '13 at 14:29

Community

1

answered Apr 06 '10 at 09:38

supercheetah

964

7

No, this will keep the socket opened until all the timeouts close them. (It will hide all the traffic from the owning process which then have no means to know it should close it.) You could use -j REJECT to return TCP reset flag, which would be then seen my the owning process (but only when the other side tries to send something). – Marki555 May 15 '15 at 17:07

score 2 · Answer 6 · answered Apr 06 '10 at 03:45

2

netstat -anp | grep 80

It should tell you, if you're running apache, "httpd" (this is just an example, use the port your application is using instead of 80)

pkill -9 httpd

or

killall -9 httpd

answered Apr 06 '10 at 03:45

Ben

310
2
5

4

try a normal kill before resorting to -9 – Thilo Apr 06 '10 at 03:49
@omfgroflmao - But it will kill the process which has opened the port ?? – Apr 06 '10 at 04:13
@codingfreak The process that's holding the port, yes it will kill it. – Apr 06 '10 at 04:48

score 2 · Answer 7 · edited Apr 22 '12 at 08:35

You could probably just find out what process opened the socket that the port is associated with, and kill that process.

But, you would have to realize that unless that process has a handler that de-initializes all the stuff that it was using (open files, sockets, forks, stuff that can linger unless it's closed properly upon termination) then you would have created that drag on system performance. Plus, the socket will remain open until the kernel realizes that that the process has been killed. That usually just takes about a minute.

I suppose the better question would be: What port (belonging to what process) do you want to stop?

If you are trying to put an end to a backdoor or virus that you found, then you should at least learn what data is going back and forth before you terminate it. (wireshark is good for this) (And the process' executable name so you can delete it and prevent it from coming back on reboot) or, if it's something you installed (like HTTPD or FTPD or something) then you should already have access to the process itself.

Usually it will have a control program (HTTPD stop|start or something). Or, if it's a system thing, you probably should not mess with it. Anyway, i thought that since everyone else is giving you the "how-to" angle, i should give you the caveats.

Very good comment. I have one program, which under termination does ot close the socket what results in described behaviour - the socket is unusable for about 60 seconds. When I stop and start that process, it is complaining for about a minute, that the address and port is already in use. The best solution is to correct badly behaving process to close properly, but sometime this is not an option. Is there a way to ask kernel checking that blocked socket sooner than in 60 seconds? — Jan Vlcinsky, Apr 15 '14 at 16:21

score 2 · Answer 8 · edited Apr 23 '15 at 06:30

2

If you want your port to be released sooner, you have to set the following value:

echo 1 > /proc/sys/net/ipv4/tcp_fin_timeout

to set it from 60 seconds (default) to 1 second

edited Apr 23 '15 at 06:30

bwDraco

46,155

answered Apr 23 '15 at 06:06

Daniel

21

score 1 · Answer 9 · answered Apr 06 '10 at 04:10

1

You could write a script which modified the iptables and restarts them. One script for adding a rule dropping all packets on the port, another script for removing said rule.

The other answers have shown you how to kill the process bound to the port - this may not be what you want. If you want the server to keep running, but to prevent connections from clients then you want to block the port, not stop the process.

answered Apr 06 '10 at 04:10

Michael Shimmins

111

@Michael Shimmins ... hmm sounds intresting as we can block the port on server side so that the client wont send any messages. – Apr 06 '10 at 04:18
Well the client can send messages all they want we've just closed the door so they can't get in. – Apr 06 '10 at 04:30

score 1 · Answer 10 · edited Jul 16 '21 at 17:15

1

Use UFW on your machine and close it. Or something like UFW.

sudo ufw deny PORT

Execute the following command, replacing the PORT placeholder with the number of the port to be closed:

On Debian:
```
sudo ufw deny PORT
```

On CentOS:

sudo firewall-cmd --zone=public --permanent --remove-port=PORT/tcp 
sudo firewall-cmd --reload

edited Jul 16 '21 at 17:15

zx485

2,279

answered Jul 16 '21 at 15:46

Lee Beck

11

score 1 · Answer 11 · answered Nov 01 '13 at 02:08

1

One more issue: sometime the kernel owns ports themselves. I know NAT routing holds some ports open for NAT use. You can not kill a process for this, this is a kernel, and a reconfiguration and a reboot is required.

answered Nov 01 '13 at 02:08

Rich Homolka

31,505

score 1 · Answer 12 · edited Nov 08 '16 at 05:59

1

I first looked for the mongo and node processes, then did the following:

ps -A | grep node

10418 pts/23   00:00:05 node

10551 pts/23   00:00:00 node

ps -A | grep mongo

10490 pts/23   00:00:00 mongod

Once identified, just kill the processes with the kill command.

kill -9 10418
kill -9 10490

Lastly, type meteor and it should be working again.

edited Nov 08 '16 at 05:59

Gareth

18,809

answered May 27 '15 at 03:46

abautista

131

Zhou Shuai-Ming · Answer 13 · 2015-09-08T06:36:21.270

1

You can use the command named killcx, closing a connection without any process to be killed.

syntax:

killcx [dest_ip:dest_port] {interface}
dest_ip              : remote IP
  dest_port            : remote port
  interface (optional) : network interface (eth0, lo etc).

example:

killcx 120.121.122.123:1234
killcx 120.121.122.123:1234 eth0

edited Sep 08 '15 at 06:36

answered Jul 29 '15 at 02:25

Zhou Shuai-Ming

11

// , Do most Linux machines have killcx? None of the ones I've tried have this killcx command available without installing packages unavailable to them with their current repository config. – Nathan Basanese Jan 14 '16 at 18:43
no, you can find the tool here: http://killcx.sourceforge.net/ – Zhou Shuai-Ming Jan 15 '16 at 01:51
// , I know I can find the tool, it's just a pain to instal that on thousands of servers. – Nathan Basanese Jan 15 '16 at 06:37
Use Puppet @NathanBasanese :) – SHOUBHIK BOSE Mar 17 '16 at 09:03

score 1 · Answer 14 · answered Oct 15 '15 at 08:45

I am aware that this answer does not answer the question itself, strictly speaking, but reading into it this might be relevant information:

The default behaviour of binding a socket to a port (and address) is that when socket is closed by abrupt termination of process, the socket will stay in TIME_WAIT for a while. This will mean you cannot immediately re-bind to this address/port. If you are developing the system itself through the standard BSD socket interface, you can (at least to some extent) control this behaviour with SO_REUSEADDR socket option. This will basically allow you to bind into the same address/port again if the socket is in TIME_WAIT status. Still one socket per port though!

However, this information should only be used as development aid, since there's a reason for TIME_WAIT to exist in the first place, already explained in the other answers.

// , Right. Of course, killing processes is not the best way to free up ports. I have noticed that when I kill the Vagrant process if it hangs, I can't vagrant up again for a while. I bet this TIME_WAIT thing has something to do with it. — Nathan Basanese, Jan 14 '16 at 18:46

score 0 · Answer 15 · answered Mar 30 '16 at 10:02

If you want no traffic over the socket but want to keep alive the process: tcpkill.

tcpkill -i eth0 host xxx.xxx.xxx.xxx and port yyyy

Will start a sniffing daemon that intercepts and trashes all traffic on that port. Very handy for testing your applications for network splits.

Manually closing a port from commandline

15 Answers15

Linked