Bug #17044 Updated: TIME_WAIT status

ID: 17044 Updated by: filippo@zirak.it Reported By: gberger@apaara.com Status: Open Bug Type: Sockets related Operating System: Linux Red Hat 7.0 PHP Version: 4.2.1 New Comment: trying to temporarily use a "daemontools" way... found a CLOSE_WAIT problem... http://bugs.php.net/bug.php?id=17964 are php-sockets well tested ?!? ;-P Filippo Previous Comments: ------------------------------------------------------------------------ [2002-06-24 10:52:27] prakash@libero.it same problem on kernel 2.2.16 and php 4.2.1 and kernel 2.2.16 and php 4.1.2... connections are accepted but cannot be closed properly. prakash ------------------------------------------------------------------------ [2002-06-24 10:20:09] filippo@zirak.it Resume: server socket (accepted) will cause a 60secs TIME_WAIT even after a socket_shutdown+socket_close ... (it's difficult it a kernel problem, as I've checked with other tcp-servers, and they behave normally...) ... hope it helps... phy ------------------------------------------------------------------------ [2002-06-24 09:12:11] filippo@zirak.it > probably, this is an apache issue. > just because i'm curious, fillipo: what kernel and what apache do you use? kernel 2.4.4 no Apache! I'm finding the same TIME_WAIT bug also with client/server (both written in php) architecture, not found with other php4 < 4.2.1... for that I think it may be a kernel or php problem (I've to check kernel), but not Apache, at least in my case. phy ------------------------------------------------------------------------ [2002-06-24 09:07:35] filippo@zirak.it the thing i do not understad is that in the praticular case described, the tcp connection opened to the browser stays in TIME_WAIT as well; this should not be, since webserv is the server in this case. probably, this is an apache issue. just because i'm curious, fillipo: what kernel and what apache do you use? ------------------------------------------------------------------------ [2002-06-19 11:13:04] gberger@apaara.com as i have discussed with others in the meantime, i think the TIME_WAIT status is not the problem: the process that is opening a tcp-connection from webserv to tixserv needs to stay in TIME_WAIT, in case its last ACK is lost and tixserv sends its FIN again. webserv is acting as client here and has to stay in TIME_WAIT for 2MSL. the thing i do not understad is that in the praticular case described, the tcp connection opened to the browser stays in TIME_WAIT as well; this should not be, since webserv is the server in this case. probably, this is an apache issue. just because i'm curious, fillipo: what kernel and what apache do you use? ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/17044 -- Edit this bug report at http://bugs.php.net/?id=17044&edit=1