tcp socks at close_wait for days without process

tcp socks at close_wait for days without process

[Markus Kolb]

Hello,
I have a problem with this close_wait state in tcp connections.

There is no process left in the process list which could belong to the
specific port.
It is known that the application has bugs, but shouldn't the Linux
kernel manage this close_wait state and free the port after a while?
I believe I could wait for months and years and the close_wait won't go
away without a reboot.

At the moment I am using a Debian kernel-image 2.4.22-1.
But with older Debian kernel-images and SuSE images (I think I have also
tried a 2.4 vanilla) you can watch this behavior, too.

I have watched a 2nd strange kernel behavior. For that I don't know how
to reproduce.
A server application listened at a specific port. The application
crashed and no process belonging to this application was in process list
anymore. But the listening socket alives for about 5 minutes although
there was no process. How this can be? A listening port without a daemon
process belonging to it?
After the 5 minutes I have rebooted.

Am I wrong about the possibilities of the kernel?

Bye
Markus

Re: tcp socks at close_wait for days without process

[Mihai RUSU]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Mon, 29 Dec 2003, Markus Kolb wrote:

> Hello,
Hi

> I have a problem with this close_wait state in tcp connections.
> 
> There is no process left in the process list which could belong to the
> specific port.
> It is known that the application has bugs, but shouldn't the Linux
> kernel manage this close_wait state and free the port after a while?
> I believe I could wait for months and years and the close_wait won't go
> away without a reboot.


CLOSE_WAIT means that the socket has received FIN from the other end and 
has send ACK but the application holding the local socket has not yet 
closed the socket (with close() or shutdown()). Are you sure there is no 
application running that holds the CLOSE_WAIT sockets (also the remote 
end should have sockets in FIN_WAIT2 state)? Try something like 
this as root: 
netstat -an | grep CLOSE_WAIT
fuser -n tcp <localport>,<remote-addr>,<remote-port>
where <localport>, <remote-addr>, <remote-port> you take them from the 
netstat output. fuser should give you the PID of the owner of the sockets 
in CLOSE_WAIT. kill it and they should dissapear.

> I have watched a 2nd strange kernel behavior. For that I don't know how
> to reproduce.
> A server application listened at a specific port. The application
> crashed and no process belonging to this application was in process list
> anymore. But the listening socket alives for about 5 minutes although
> there was no process. How this can be? A listening port without a daemon
> process belonging to it?

Strange. Try fuser again (fuser -n tcp <local-listening-port>) to see if 
it pops anything out.

> Bye
> Markus

- -- 
Mihai RUSU                                    Email: dizzy@roedu.net
GPG : http://dizzy.roedu.net/dizzy-gpg.txt    WWW: http://dizzy.roedu.net
                       "Linux is obsolete" -- AST
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQE/8Wb3PZzOzrZY/1QRAouxAKDWkaCOBS2uuZeo3uu6WxDLZWw07wCdFeVD
C4BT0Dkh7gZpRwESEA4+ZTE=
=usNX
-----END PGP SIGNATURE-----

Re: tcp socks at close_wait for days without process

[Markus Kolb]

Mihai RUSU wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On Mon, 29 Dec 2003, Markus Kolb wrote:
[...]
> netstat -an | grep CLOSE_WAIT
> fuser -n tcp <localport>,<remote-addr>,<remote-port>
> where <localport>, <remote-addr>, <remote-port> you take them from the 
> netstat output. fuser should give you the PID of the owner of the sockets 
> in CLOSE_WAIT. kill it and they should dissapear.

Well the process list has been very short. So I am pretty sure that 
there hasn't been any processes from the application.
Could it be that the socket which first belongs to the crashed 
application is bound to the father process of this crashed application?
This would be a bash or init.

Thanks for the hint with fuser.
Before the next reboot I will try to reproduce and will use the fuser 
command to see more details.

Bye