I have used exec 3<>/dev/tcp/ to establish a TCP connection with And I have received as well as sent a few messages with the pipe command.

Now, I want to terminate the TCP connection. But, with ss -anpet I can see that bash itself holds this connection, without forking a child process.

I tried to send signal 9 and 15 to the bash process, but as you know, bash cannot kill itself.

So, can I terminate the TCP connection I have established without terminating the pts I am using (neither killing it by root nor sending Ctrl+D)?

  • Could you get another shell & kill bash with that shell?
    – trysis
    Jun 12, 2016 at 21:40
  • 3
    bash certainly can kill itself - though that's not actually what you want to do here!
    – psmears
    Jun 12, 2016 at 22:50
  • @TJM to make this fascinating question more useful to others, could you please elaborate on the pipe command you're using and which I can't find on my system? Which package does pipe comes from? What (example) parameters can you pass to it to send/receive data over the /dev/tcp/... connection? Thanks.
    – arielf
    Jun 13, 2016 at 21:50
  • @arielf Typically, I am a beginner of Computer Science, and I found this kind of usage from a bash shell script called sedbot, you can find it on Github. Yes, I cannot find any files in /dev/tcp, even cannot find /dev/tcp itself. But, it seems a special usage that you can send/receive data with pipe and this kind of files. It is said that use /dev/tcp/ip/port for tcp connections, and /dev/udp/ip/port for udp packages. For my English is not very good, I don not know how to explain it properly. Please feel free to edit the question and post an answer.
    – TJM
    Jun 14, 2016 at 4:00
  • @TJM thanks. The question was about the pipe command that you mention. I looked at https://github.com/clsr/sedbot/blob/master/sedbot.bash. There's no pipe command there. It defines two functions: readmsg and sendmsg to read/write from/to the connection respectively. readmsg uses IFS= read -r -u 3 -t "$READ_TIMEOUT" line to read from file-descriptor 3 into the variable line, and sendmsg uses echo "$(date +%s.%N) >>> $line" >&4 to write into file descriptor 4. Anyway, this clarifies the full method. The "pipe command" mention still remains a mystery to readers.
    – arielf
    Jun 14, 2016 at 5:23

1 Answer 1


That command opened the connection on file descriptor 3. So to close the connection, you need to close file descriptor 3. To do so:

exec 3<&-
  • 1
    Will this do a proper shutdown(3) call, or just close(2) the file descriptor?
    – Kevin
    Jun 13, 2016 at 3:23
  • Does a close, but shutdown is no more proper than close. shutdown's only real use is when you only want to close one side of a duplex socket.
    – phemmer
    Jun 13, 2016 at 3:26
  • 4
    A shutdown sends a FIN, while a close sends a RST. These are materially different things.
    – Kevin
    Jun 13, 2016 at 3:29
  • 2
    @Kevin RST is caused by closing the socket without reading all the data from it first. If you read to the end of the data and then do a close, the close will send a FIN.
    – kasperd
    Jun 13, 2016 at 7:04
  • @kasperd: In the UNIX socket API, the only way to know whether there is data pending is to either try to read from a nonblocking socket, or call something like select(), and I don't believe bash provides for either option.
    – Kevin
    Jun 13, 2016 at 7:08

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .