Bug #1149
closedhandle-req time too long
Description
Yesterday,i upgraded lighttpd to 1.4.15 by ports (FreeBSD 6.2 amd64)
Server-Status shows:
74.6.68.* 0/0 0/0 handle-req 19513 www.***.com /p/p_index.php 202.108.23.* 0/0 0/0 handle-req 20279 www.***.com /p/p_p_list.php 60.18.29.* 0/0 0/0 handle-req 25046 www.***.com /p/p_s_xml.php 218.20.59.* 0/0 0/0 handle-req 20409 www.***.com /t/t_a_xml.php
is this a bug ?
--------------------------- Hostname 211.155.224.* () Uptime 20 hours 3 min 57 s Started at 2007-04-25 01:46:45 absolute (since start) Requests 501 kreq Traffic 5.93 Gbyte average (since start) Requests 6 req/s Traffic 86.13 kbyte/s average (5s sliding average) Requests 15 req/s Traffic 83.01 kbyte/s legend . = connect, C = close, E = hard error r = read, R = read-POST, W = write, h = handle-request q = request-start, Q = request-end s = response-start, S = response-end 30 connections hhrhhrWrrrrrWrrrhrrrrrrrrrrrrh ----------------- fastcgi.active-requests: 6 fastcgi.backend.0.0.connected: 154186 fastcgi.backend.0.0.died: 0 fastcgi.backend.0.0.disabled: 0 fastcgi.backend.0.0.load: 6 fastcgi.backend.0.0.overloaded: 0 fastcgi.backend.0.load: 6 fastcgi.requests: 154186
-- ruanchunping
Updated by Anonymous almost 17 years ago
today's status:
74.6.68.* 0/0 0/0 handle-req 99075 www.***.com /p/p_index.php 202.108.23.* 0/0 0/0 handle-req 99841 www.***.com /p/p_p_list.php 59.40.155.* 0/0 0/0 handle-req 78446 www.***.com /p/p_v_v2.php 60.18.29.* 0/0 0/0 handle-req 104608 www.***.com /p/p_s_xml.php 218.20.59.* 0/0 0/0 handle-req 99971 www.***.com /t/t_a_xml.php 218.67.240.* 0/0 0/0 handle-req 8297 www.***.com /t/t_a_xml.php 202.108.23.* 0/0 0/0 handle-req 23922 www.***.com /p/p_v_v2.php 60.176.206.* 0/0 0/0 handle-req 21225 www.***.com /p/p_n.php 60.176.206.* 0/0 0/0 handle-req 21257 www.***.com /p/p_n.php 219.148.86.* 0/0 0/0 read 3 219.141.236.* 0/0 0/0 read 2 219.141.236.* 0/0 0/0 read 3 .....
fastcgi.active-requests: 9 fastcgi.backend.0.0.connected: 288341 fastcgi.backend.0.0.died: 0 fastcgi.backend.0.0.disabled: 0 fastcgi.backend.0.0.load: 9 fastcgi.backend.0.0.overloaded: 0 fastcgi.backend.0.load: 10 fastcgi.requests: 288341
fastcgi.server = ( ".php" =>
(( "socket" => "/tmp/php-fastcgi.socket",
"bin-path" => "/usr/local/bin/php-cgi",
"min-procs" => 1,
"max-procs" => 1,
"max-load-per-proc" => 4,
"bin-environment" => (
"PHP_FCGI_CHILDREN" => "64",
"PHP_FCGI_MAX_REQUESTS" => "5000" ),
"bin-copy-environment" => (
"PATH", "SHELL", "USER" ),
"broken-scriptfilename" => "enable",
"idle-timeout" => 20
))
)
-- ruanchunping
Updated by Anonymous almost 17 years ago
I think this is not mod_fastcgi's problem.
221.237.198.* 0/0 0/0 handle-req 866 www.***.com /service/proxy/*/http:/www.yupoo.com/api/rest/ 221.237.198.* 0/0 0/0 handle-req 867 www.***.com /service/proxy/*/http:/www.yupoo.com/api/rest/ 61.157.139.* 0/0 0/0 handle-req 928 www.***.com /service/proxy/*/http:/www.yupoo.com/api/rest/ 60.12.190.* 0/0 0/1038 handle-req 731 www.***.com /service/proxy/*/http:/www.yupoo.com/api/rest/ 221.237.198.* 0/0 0/0 handle-req 865 www.***.com /service/proxy/*/http:/www.yupoo.com/api/rest/
the uri '/service/proxy/*/URL' will redirect to my Squid proxy server by mod_proxy, act as AJAX-cross-domain Server.
-- ruanchunping
Updated by stbuehler over 15 years ago
- Status changed from New to Fixed
- Resolution set to invalid
I don't see a problem.
Updated by adrenalin over 15 years ago
- Status changed from Invalid to Reopened
I have the very same problem,
lighttpd-1.4.20 (ssl) - a light and fast webserver on freebsd 7
92.115.105.143 handle-req 99890 .....md.com /takeupload.php (/takeupload.php) /home.........md/takeupload.php
89.28.47.48 handle-req 99286 .....md.com /details.php?id= (/details.php?id=480083) /home.........md/details.php
86.106.247.97 handle-req 92583 www......md.com /search.php?search_str= (/search.php?search_str=dedication) /home.........md/search.php
212.56.209.26 handle-req 92583 .....md.com /download.php?returnto=... (/index.php) /home.........md/index.php
92.114.235.252 handle-req 92102 .....md.com /details.php?id=487435&viewcomm=4766665 (/details.php?id=487435&viewcomm=4766665) /home.........md/details.php
89.40.113.97 handle-req 92100 www......md.com /download.php (/download.php/489015/v...) /home.........md/download.php
92.115.77.149 handle-req 92104 .....md.com /search.php?search_str=2008&page=1 (/search.php?search_str=2008&page=1) /home.........md/search.php
...............
It's a server behind a lighttpd(1.4.20 freebsd 6.1) proxy (proxy module). The proxy server don't have such a problem. Maybe it's because of a php scripts I don't know (I have max-execution time 30 in php so it shouldn't be it).
The problem is that they never go away, and eat the cpu, and I have no other choice than to restart lighttpd every some minutes.
Another problem is when the workers is down(or maybe when it's not fast enoguth to process everything) lighttpd proxy for some reason start eat all the cpu.
If somebody can help me do a patch to not allow handle-req to wait so long, for example if it's more than 30 second, then die. I have though server.max-write-idle=30
server.max-read-idle=3 but it doesnt seem to help, and I don't find a param ModFastCGI to put some max-execution time on processes..
Updated by adrenalin over 15 years ago
I'm also amd64, maybe that's because of that ?
Updated by adrenalin over 15 years ago
http://bugs.php.net/bug.php?id=45254 "PHP does not time out when accepting for connections while working as FastCGI" I think it's releated, so it might be because of php
Updated by stbuehler over 15 years ago
- Target version changed from 1.4.20 to 1.4.21
- Patch available set to No
Updated by icy about 15 years ago
- Status changed from Reopened to Need Feedback
- Assignee deleted (
jan) - Target version changed from 1.4.22 to 1.4.23
Is this still valid for the current version?
Updated by stbuehler almost 15 years ago
- Status changed from Need Feedback to Missing Feedback
Updated by samkline over 14 years ago
- Status changed from Missing Feedback to Reopened
- Target version changed from 1.4.23 to 1.4.x
This is still an issue in 1.4.24. Using fastcgi with PHP 5.3.1, I get ~3 dozen handle-req building up every day (from about ~1mil total requests per day). Server crashes almost every day as well, at peak time.
Related to bug #575 ?
I can give you guys any more information you need.
php-cgi processes are created via spawn-fcgi.
fastcgi.server = (
".php" => ((
"socket" => "/var/www/sockets/sock.nobody",
"idle-timeout" => 300
))
)
Updated by stbuehler over 14 years ago
- Missing in 1.5.x set to No
What do you mean with "server crashes"? segfault? backtrace? What kind of requests are stuck in "handle-req" ? POST/GET/...?
Updated by gstrauss about 8 years ago
- Status changed from Reopened to Need Feedback
@samkline, @adrenaline, @Anonymous, while I know this is old, if you're still seeing this issue, I'd like to dig into it. Would you be willing to test some patches?
Updated by gstrauss about 8 years ago
- Status changed from Need Feedback to Patch Pending
- Target version changed from 1.4.x to 1.4.40
Submitted pull request https://github.com/lighttpd/lighttpd1.4/pull/53
For those seeing the issue reported in this ticket, please test the patch and report back if the patch resolves the issue. Thank you.
Updated by gstrauss about 8 years ago
- Related to Bug #1829: lighttpd leaves CLOSE_WAIT connections added
Updated by gstrauss about 8 years ago
- Related to Bug #647: handle-req timeout added
Updated by gstrauss about 8 years ago
- Status changed from Patch Pending to Fixed
- Target version changed from 1.4.40 to 1.4.x
I believe this issues has since been fixed in historical commits, potentially this one:
commit d00e1e79b94e0f4da35292d2293595dac02993c7
Author: Stefan Bühler <stbuehler@web.de>
Date: Sat Feb 7 13:32:54 2015 +0000
[connections] fix bug in connection state handling
if a request was finished (con->file_finished = 1) and the state
machine was triggered, but the write queue was empty, it didn't
actually finish the request.
From: Stefan Bühler <stbuehler@web.de>
git-svn-id: svn://svn.lighttpd.net/lighttpd/branches/lighttpd-1.4.x@2973 152afb58-edef-0310-8abb-c4023f1b3aa9
Other commits related to closing connections: svn r2636 (476c5d48) and svn r2645 (20c4cd55)
See #1829 for further discussion, and please re-open this ticket if you are still seeing this issue.
Also available in: Atom