httpd-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chirouze Olivier" <>
Subject [users@httpd] Apache 2.0.58 + Solaris 5.9: status "...reading..." & TCP state "FIN_WAIT_2"
Date Fri, 26 Jan 2007 15:56:46 GMT
Hi all,

I'm facing a quite tricky situation with Apache 2.0.58 running on
Solaris 5.9.

Apache is running as a reverse proxy (mod_proxy + mod_rewrite).
The maximum concurrent connections is set to 150.

Because we reached the maximum a few times and got the reverse proxy
saturated, we started monitoring the Apache status page (/status).
We noticed that many requests were in the "..reading.." state (up to
40!), and they block a lot of slots.

At first, we upgraded from 2.0.47 to 2.0.58 because it seemed there was
a security hole in the earlier, fixed in 2.0.48.
I found some explanation here:

The thing is, the situation is starting to appear again with 2.0.58.

We've gone down to Unix and found that most of these requests were in
"FIN_WAIT_2" TCP state, and for a while (approx. 8min!!).

We found this:
What it says, in a word, is that these things can happen and are
"normal": the connection stays in "FIN_WAIT_2" state until the timeout,
if clients do not close it properly. They just say it can be a problem
on the Unix point of view because.
I don't know if this is still true for 2.0 because the article was just
copied from 1.3. The thing is, it says that "The connections in
FIN_WAIT_2 do not tie up an httpd process". For us, IT DOES! Every
"..reading.." request happend to be in the "FIN_WAIT_2" state.

We have contacted Sun to get their opinion. The short answer is "you can
change the FIN_WAIT_2 timeout but be careful because wrong tuning will
have negative impact. Maybe you should wonder why these connections stay
alive". As far as I understood, the connection is not closed by the
client. The server (Apache) does nothing wrong. But maybe it does, as it
doesn't leave the process free?

My questions are:
Does anyone have heard about similar problems?
Why do these connections hold a process of Apache while the
documentation says it doesn't?
Do you recon tuning the Unix timeout would help? (current value of
tcp_fin_wait_2_flush_interval: 675000 ms - 11min!! This looks just

Thanks in advance,


I&0 Infrastructure
Volvo Information Technology

The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:> for more info.
To unsubscribe, e-mail:
   "   from the digest:
For additional commands, e-mail:

View raw message