I have a server process and a client process running on the same Linux machine.
Sometimes when I kill -9
the client, I see with tcpdump
that a FIN, ACK
message is sent. Of course the dead client couldn't have done it because he's dead brutally with SIGKILL
. So I guess Linux OS handles the connection closing.
Sometimes I don't see any connection-close-handling and the connection stays “ESTABLISHED” (by netstat
).
I always see a connection being closed in Linux ubuntu 4.4.0-53-generic
.
Sometimes I see a connection being closed in Linux 3.13.11
(pure kernel, not Ubuntu).
My questions are:
- Does Linux handles closing connections?
1.1 InSIGKILL
?
1.2. When application closed properly, but doesn't callclose()
? - Did this functionality change between kernel versions
3.13.11
and4.4.0
? Does Ubuntu has anything with it? - What if those two processes weren't on the same Linux machine: would it behave the same?
- Why does the connection sometimes stay “ESTABLISHED”?
- I'm aware of TCP
keepalive
socket options. If Linux really handles closing the connection. Why do they exist? Only if theFIN, ACK
packet drops?
exit()
. Andexit()
internally callsclose()
on all open file descriptors. So the behavior withclose()
should be a subset of the behavior withexit()
, which, in turn, should be a subset of the behavior withkill
. (And, conversely, the signal-handling code and theexit()
function don’t know anything about the networking subsystem, so they won’t do anything to an open connection except close the file descriptor.) I can’t explain why you’re seeing inconsistent behavior.udhcpc
and the unnamed service client are in the process tree, and what actually opened the client socket and spawnedudhcpc
, everything will become clear.