Re: Socket stuck in CLOSE_WAIT state

Tom Holroyd (tomh@nibh.go.jp)
Wed, 28 Apr 1999 11:16:12 +0900 (JST)


On Tue, 27 Apr 1999, Alan Cox wrote:

>Its a bug. I've also been sent a possible fix for it if you want it. Its
>sufficiently hard to cause (needs to be local) and peculiar I've got the fix
>scheduled for 2.0.38pre1. "Fixing" a TCP bug this close to .37 is likely to
>be bad engineering decision 8)

I've had these sitting around for a few days, and they are very easy to
reproduce (this was with 2.2.6):

Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 48 0 bhalpha1.nibh.go.:shell bhmarvin.nibh.go.j:1023 CLOSE
tcp 45 0 bhalpha1.nibh.go.:shell bhmarvin.nibh.go.j:1021 CLOSE_WAIT
tcp 47 0 bhalpha1.nibh.go.:shell bhmarvin.nibh.go.j:1022 CLOSE
tcp 46 0 bhalpha1.nibh.go.:shell bhmarvin.nibh.go.j:1022 CLOSE
tcp 46 0 bhalpha1.nibh.go.:shell bhmarvin.nibh.go.j:1022 CLOSE
tcp 44 0 bhalpha1.nibh.go.:shell bhmarvin.nibh.go.j:1023 CLOSE

I just did a mess of "rcp" from marvin (which is on the same network
segment as the alpha) pulling stuff and inetd on the alpha eventually
killed it with

inetd[223]: shell/tcp server failing (looping), service terminated

kill -HUP <inetd> was required to get it going again, and the tcp socket
remained with stuff in the recv-q.

which (Alan pointed out to me) can be fixed with this:

shell stream tcp nowait.120 root /usr/sbin/tcpd in.rshd
^^^^
(the default is 40 per second) but the point is it's easy to generate.
I'll have a look at that patch...

Dr. Tom Holroyd
I would dance and be merry,
Life would be a ding-a-derry,
If I only had a brain.
-- The Scarecrow

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/