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


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

[Mihai RUSU]

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

Post by Markus Kolb
Hello,

Hi

Post by Markus Kolb
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.

Post by Markus Kolb
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.

Post by Markus Kolb
Bye
Markus

- --
Mihai RUSU Email: ***@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-----
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

[Markus Kolb]

Post by Mihai RUSU
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

[...]

Post by Mihai RUSU
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

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