Closing sockets
Alex Parfenov
Is there a command for root to close any arbitrary connected socket (as
seen in the output of 'netstat -a')
That is, if some program was killed (namely Informix oninit), but did
not close sockets, I want to go and manually close it from the command
line. I guess I need an equivalent of 'ipcrm' but for network sockets.
Thanks a lot,
Alex Parfenov
fernando
closed.
--
---------
Real e-mail: sanabriaf at yahoo dot com
This are my personal opinions
Michael Wojcik
Is this a SCO or a Linux question? You certainly don't need to
crosspost this to three groups. I've eliminated alt.os.linux from
followups; the original poster should trim the list down to the one
appropriate group.
[Quoted text converted to canonical form.]
In article <3847FAD1...@is.not.my.real.email>, fernando <th...@is.not.my.real.email> writes:
> Alex Parfenov wrote:
> > Is there a command for root to close any arbitrary connected socket (as
> > seen in the output of 'netstat -a')
> > That is, if some program was killed (namely Informix oninit), but did
> > not close sockets, I want to go and manually close it from the command
> > line. I guess I need an equivalent of 'ipcrm' but for network sockets.
> As far I know when a process dies all the files (including sockets) are
> closed.
When a process dies, all of its file descriptors are indeed closed,
and that includes sockets.
However, a socket is not a TCP conversation. It's just an endpoint
for the API. What netstat shows is the status of TCP conversations
(and other network resources, of course), not the status of sockets.
In typical TCP/IP-under-sockets implementations, when the last socket
referring to a given TCP connection is closed (by API call or process
exit), the stack sends a FIN to the peer (indicating that it will
send no more data on that connection) and the connection enters the
TCP state FIN_WAIT_1. What happens after that depends on what the
peer does, but eventually the connection will probably enter TIME_WAIT,
and then after the 2MSL timeout (typically a few minutes) disappear
altogether.
The main exception is when the connection to the peer is completely
lost, eg. because the peer was a Windows machine and crashed or was
power-cycled. In that case, the protocol standard requires that the
connection remain in FIN_WAIT_1 (if the FIN didn't get ACKed) and
periodically retransmit the FIN until it gets an ACK or an RST (if
the peer comes back up and rejects the FIN), or possibly in
FIN_WAIT_2 (or conceivably CLOSING, if we managed to do a simultan-
eous close and then lost the line). We could wait forever in
FIN_WAIT_2 or CLOSING, according to the TCP spec. However, many
implementations eventually bump a stuck FIN_WAIT_2 or CLOSING
connection if they don't hear from the peer.
So the upshot is that killing a process does not terminate TCP
connections it had open, even if it was the only local process that
had a descriptor for those connections. And most Unixes don't
provide a way to force those connections closed. There's a good
reason for that: important state information is being kept there,
and forcing the local state to CLOSED could conceivably corrupt
later conversations.
On the other hand, stuck connections consume resources, and so some
stacks (eg. OS/390's, I think) do provide a mechanism to terminate
a connection. In theory you should be able to change the state of
a TCP connection manually using adb and /dev/kmem. (I tried that
once on AIX without success, but I wasn't trying very hard.)
Generally that's not something you want to do, though.
--
Michael Wojcik michael...@merant.com
AAI Development, MERANT (block capitals are a company mandate)
Department of English, Miami University
This year's runner-up in the All-Usenet Creative Use Of English In A
Quasi-Legal But Probably Completely Ineffectual Signature Statement:
Disclaimer : I am a free denizen of this world and statements are of mine
and solly mine. Nobody dare sue me as you may end up even loosing your
attorney fees.
-- Sridhar (holag...@hotmail.com)