I have some dead connection in one application which is in hanged state if client machine is dead.


Is there a way to terminate these option from linux command line without restarting the server?

After search I found solution called as tcpkill. But it will not work for me. As it permanently blocks that ip.

  • 3
    The answer on using the ss command is much easier and more general than the others.
    – nealmcb
    Nov 4, 2019 at 20:02

10 Answers 10


On linux kernel >= 4.9 you can use the ss command from iproute2 with key -K

ss -K dst dport = 49029

the kernel have to be compiled with CONFIG_INET_DIAG_DESTROY option enabled.

  • 2
    For linux, this is really the best way and pretty much the only way if you have idle connections (tcpkill could not work). However, I'll admit that I've not inspected killcx but it feels like a lot of security software would prevent that from working unless you modify your iptables to allow these spoofed packets through. May 21, 2019 at 17:32
  • Thanks! Worked like a charm with sudo ss -K .... on Ubuntu Bionic 18.04 LTS. I had a tmux process that was stuck at a small screen size because of a remote, but dead, but not timed-out connection. All fixed!
    – nealmcb
    Nov 4, 2019 at 20:03
  • 2
    ss: invalid option -- 'K' ubuntu 18.04.5 LTS
    – Alexey Sh.
    Mar 18, 2021 at 13:06

Originally from: http://rtomaszewski.blogspot.sk/2012/11/how-to-forcibly-kill-established-tcp.html

To "kill" a socket, you must send a TCP reset packet. To send it (and be accepted by the other side), you must know the actual TCP sequence number.

1) The already mentioned tcpkill method learns the SEQ number by passively sniffing on the network and waiting for valid packets of this connection to arrive. Then it uses the learned SEQ number to send RSET packets to both sides. However if the connection is idle/hanged and no data flows, it won't do anything and will wait forever.

2) Another method uses perl script called killcx (link to Sourceforge). This actively sends spoofed SYN packets and learns the SEQ number from the answer. It then sends RSET packets the same way as tcpkill.

Alternatively approach (based on what you want to achieve) is to use gdb debugger to attach to a process owning this socket/connection and issue close() syscall on its behalf - as detailed in this answer.

If you want to deal only with hanged connections (the other side is dead), there are various timeouts (TCP keepalive for example), which should automatically close such connections if configured properly on the system.

  • Would it work if we simply closed the TCP socket by its file descriptor (fd)? exec fd>&- Jan 10, 2018 at 7:18
  • @AlexanderGonchiy for live connections it would prevent the process to respond to packets, so it would cause the connection to timeout. For idle connections nothing would happen. I'm not sure if kernel would send anything to the network on closing the fd.
    – Marki555
    Jan 11, 2018 at 9:41
  • I have sniffed the sequence number. What should i do then? Dec 29, 2018 at 11:33

tcpkill might do it for you. In Ubuntu it is in the dsniff package.

Something like:

$ sudo tcpkill -i wlan0 host

(or some other tcpdump like expression for what connection to kill).

  • 4
    This works only if the connection is transmitting anything. It will not work for hanged/idle TCP connections (see my answer for details)
    – Marki555
    May 15, 2015 at 17:02

Do - as root netstat -tunp|grep 49029. The last column of the output should show you the PID and program name of the process responsible for that connection.

If you are lucky there is a single process for just that connection.

If you are unlucky it gets more complicated (the PID is responsible for more than just that one connection). What kind of service is this?

Why do you want to terminate that session?

  • 10
    I can't kill that process. It is gearman server. I want to just close the connection.
    – Vivek Goel
    Apr 10, 2013 at 13:34
  • After that: sudo kill PID
    – sapeg
    May 4 at 9:18

tcpkill cannot close a dead (hanged) connection. It is based libpcap, it construct a packet to sent FIN packet. If the connection is already dead, it cannot get the right sequence number.

The only way is to close the process, so makes everywhere is NOT SPOF.


You may try to use iptables REJECT with --reject-with tcp-reset, which would send RST to remote when it matches a packet.


Adding to Marki555 answer which is a great list of options on how to do this.

I found another option - which is long - but also works for idle connections. It is to use a kernel debugger to get the TCP sequence number and then send FIN packets (I believe) using hping3. From https://blog.habets.se/2017/03/Killing-idle-TCP.html


DROP packets for incoming/outgoing IP address using:

sudo iptables -A INPUT -s -j DROP
sudo iptables -A OUTPUT -d -j DROP

Undo the change when finished and delete the rules you added using:

sudo iptables -D INPUT -s -j DROP
sudo iptables -D OUTPUT -d -j DROP

This repo https://github.com/caruccio/tcp_killer/ which is a python3 fix for https://github.com/google/tcp_killer does the job for me. And it works in both Linux and macOS.

It uses the debugger approach mentioned by Marki555 and described in this answer.


To kill port 34700 have used this command:

fuser -k 34700/tcp

Ref.: https://stackoverflow.com/questions/750604/freeing-up-a-tcp-ip-port

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.