killing sockets in red hat linux

[Oved]

Hey,

I would like to know how can I kill/remove a socket in linux.

In HP-UX I can use ndd to do this, but linux doesn't have ndd.

Thanx,
Oved

[Fred Ruffet]

What do you mean by "kill/remove" a socket ?
Do you want to close an open port ?

For me ndd helps tuning some network parameters. This can be an equivalent to Linux sysctl, which offers to tune kernel parameter, and, in your case, network ones.

Regards,

Fred

[Oved]

Hey,

I mean to close an open socket...
ndd can do it in HP-UX

(There are applications with a "bug" that causes sockets in "CLOSE_WAIT" state to remain in the system, and it causes problems with that applications. )

Thanx,
Oved

[Huc_1]

One way to do this could be

ex: (from root)
#lsof -i | grep "CLOSE_WAIT"
# mozilla-b 5914 himself 3u IPv4 49447 TCP 10.22.55.11:ssh->whatever.dom:32798 (CLOSE_WAIT)

then you could use some form of KILL on pid 5914

Hope this help you out.

Jean-Pierre

[Oved]

It doesn't help so much, because in the cases I want to solve the socket is hang without a process.

I am looking for a solution just like ndd in HP-UX.

Thanx,
Oved

[Steven E. Protter]

Since ndd does not exist in Linux, a few wild suggestions:

1) Find the source code for ndd, port it and compile it in Linux
2) try the binaries and see if they work.
3) Write a program in c that does what you want.

SEP

[Olivier Drouin]

a socket in close_wait without a process?? I'd like to see this.

[rick jones]

the ndd thing in HP-UX is a kludge that should only be used by the truly desparate until the bug(s) in the application(s) can be fixed. As such, I'm not terribly surprised that there might not be a ready replacement in Linux. If someone becomes "dependent" on the ndd connection closing stuff, they are only adding little to little to eventually have a big pile.

CLOSE_WAIT without a process would indeed be a neat trick, and would imply a bug in the transport/kernel. however, unless I read too fast, I think there wasn't mention of the process going away, just lingering and leaving connections in CLOSE_WAIT (bug 1) and then if I extrapolate, leaving things unable to restart (bug 2 - not setting SO_REUSEADDR - but that one is a WAG)