logo
Apache Lounge
Webmasters

 

About Forum Index Downloads Search Register Log in  RSS Apache Lounge  


Keep Server Online

If you find the Apache Lounge, the downloads and overall help useful, please express your satisfaction with a donation.

or

Bitcoin

A donation makes a contribution towards the costs, the time and effort that's going in this site and building.

Thank You! Steffen

Your donations will help to keep this site alive and well, and continuing building binaries. Apache Lounge is not sponsored.



Post new topic   Forum Index -> Apache View previous topic :: View next topic
Reply to topic   Topic: Threads stuck in "Logging" state
Author
CamaroSS



Joined: 24 Jan 2013
Posts: 73
Location: RF, Tver

PostPosted: Fri 02 Aug '13 8:43    Post subject: Threads stuck in "Logging" state Reply with quote

I have Apache 2.4.6 x64 installation. With the lapse of time, more and more threads appear that are stuck in "L" state. They are all gone after httpd restart, leaving 408 errors in access logs. What can be the reason? Can mod_log_rotate be involved? Currently it's set to rotate every 2 days.
Back to top
Steffen
Moderator


Joined: 15 Oct 2005
Posts: 2850
Location: Hilversum, NL, EU

PostPosted: Fri 02 Aug '13 10:32    Post subject: Reply with quote

Dealing here with the same. Does not harm when you have enough threads available (ThreadsPerChild). Happens here also sometimes that after a long time (weeks) they are cleaned up.

Discussed it back in the early days of 2.3/2.4 with the developers, with the subject "Hanging L's".

It happens here only with the bigger binaries/pdf's downloads when a client downloads Partial content (206)with a "bad" client and/or slow connection. And indeed get also during that downloads 408's.

Steffen
Back to top
Steffen
Moderator


Joined: 15 Oct 2005
Posts: 2850
Location: Hilversum, NL, EU

PostPosted: Fri 02 Aug '13 10:41    Post subject: Reply with quote

Sorry to tell above:

It started happening with 2.2.

The default for Timeout has been reduced in 2.4 from 300 to 60. The developers said that if
there are complaints from users, the new value may be too low and we should maybe reconsider the new value.

So I have now Timeout 300 again, it reduces the issue.


Steffen
Back to top
CamaroSS



Joined: 24 Jan 2013
Posts: 73
Location: RF, Tver

PostPosted: Fri 02 Aug '13 14:53    Post subject: Reply with quote

Thanks for the answer. I think I'll just stick with a scheduled httpd restart, as it works well and noone seems to be affected.
Back to top
CamaroSS



Joined: 24 Jan 2013
Posts: 73
Location: RF, Tver

PostPosted: Tue 13 Aug '13 14:31    Post subject: Reply with quote

I've lowered TimeOut directive to 30 sec., and the issue is gone for like 3 days now. I think it could be lowered further to 20 sec. or so, as long as I use FastCGI. Manual says
Quote:

The TimeOut directive defines the length of time Apache httpd will wait for I/O in various circumstances:

When reading data from the client, the length of time to wait for a TCP packet to arrive if the read buffer is empty.
When writing data to the client, the length of time to wait for an acknowledgement of a packet if the send buffer is full.


So why should we wait for 5 MINUTES in such situations?
Back to top
James Blond
Moderator


Joined: 19 Jan 2006
Posts: 6890
Location: Germany, Next to Hamburg

PostPosted: Wed 14 Aug '13 0:40    Post subject: Reply with quote

I have it a longer time to 32 seconds. Why 32 and not 30? Cause 30 seconds at max a PHP my consume before it stops automaticly. The last 2 seconds are for the other stuff Wink
Since KeepAliveTimeout default is 5 seconds, I think you can easily reduce the timeout to what ever the longest time a scripts needs to run + 2 seconds.
Back to top
CamaroSS



Joined: 24 Jan 2013
Posts: 73
Location: RF, Tver

PostPosted: Wed 14 Aug '13 7:06    Post subject: Reply with quote

When PHP is in FastCGI mode, this directive does not affect any big uploads or long running scripts which demand more than 30 sec. In my case, it just affects clients with bad connection. Anyway, "L"'s are back again, so it didn't solve the problem.
Back to top
CamaroSS



Joined: 24 Jan 2013
Posts: 73
Location: RF, Tver

PostPosted: Sun 18 Aug '13 9:18    Post subject: Reply with quote

It's strange, but it seems that this problem occurs only when I operate via RDP. As long as I don't touch it, it runs just fine... Well, maybe it's just me)))
Back to top
Steffen
Moderator


Joined: 15 Oct 2005
Posts: 2850
Location: Hilversum, NL, EU

PostPosted: Wed 27 Nov '13 11:48    Post subject: Reply with quote

I see with 2.4.7 no "hanging L's" anymore. Timeout fixes in APR 1.5.0 seems to solve it.
Back to top
DonatasC



Joined: 18 Dec 2014
Posts: 1

PostPosted: Fri 19 Dec '14 13:05    Post subject: Apache 2.4.9 x64 + mod_security 2.8.0 -> many "L&quo Reply with quote

Production system is using Apache 2.4.9, and everything was fine (no "L") till I have added mod_security 2.8.0 module (with OWASP rule set). Then status screen started showing many "L" connections.
Apache eventually restarts, but some client request are not served (browser time-out's, Apache logs don't even log the request), and this was the main reason to exclude the mod_security module.

Has anybody observed such mod_security influence?
Back to top
James Blond
Moderator


Joined: 19 Jan 2006
Posts: 6890
Location: Germany, Next to Hamburg

PostPosted: Sat 20 Dec '14 23:11    Post subject: Reply with quote

At least I can say that apache lounge with mod security had these problems with the hanging L while I without mod security did not had that issues. That is only my personal experience.
Back to top
CamaroSS



Joined: 24 Jan 2013
Posts: 73
Location: RF, Tver

PostPosted: Mon 22 Dec '14 13:36    Post subject: Reply with quote

I've experiencing this problem on the setup without mod_security. Glad it's gone now.
Back to top


Reply to topic   Topic: Threads stuck in "Logging" state View previous topic :: View next topic
Post new topic   Forum Index -> Apache