Bug #220
closedcgi cpu load/high memory usage
Description
using 1.3.16 quite nicely upgraded to 1.4.0 and lost cgi functionality.. upgraded to 1.4.1 and have (what looks like) and old problem come back again.
http://www.poklib.org/html/online_databases.php I have some cgi's that are just simple hit counters.
sends cpu through the roof as well as ram usage:
928 www 50 0 134M 132M RUN 0:22 64.55% 64.50% lighttpd
when this happens I get the following entry in error.log:
2005-08-22 11:32:46: (connections.c.707) missing cleanup in compress
-- bcook-pok
Files
Updated by Anonymous over 19 years ago
uname -srm
FreeBSD 4.11-RELEASE-p11 i386
gcc -v
Using builtin specs.
gcc version 2.95.4 20020320 [[FreeBSD]]
(for what it's worth.. )
-- bcook-pok
Updated by Anonymous over 19 years ago
poklib.org/~bcook/lighttpd-3.trace.bz2
MD5 (lighttpd-3.trace.bz2) = 5c1ae4c12d3649ec46f07526434593a6
984K lighttpd-3.trace.bz2
-- bcook-pok
Updated by jan over 19 years ago
- Status changed from New to Assigned
ok, this happens if between shutdown of the script and the close of the connection is a larger gap.
#!/usr/bin/perl $| = 1; print "Status: 302 Moved\r\nLocation: http://localhost:1025/\r\n\r\n"; sleep 10;
Updated by jan over 19 years ago
Please verify that changeset r613 fixes this problem.
Updated by Anonymous over 19 years ago
Seems to be working fine. I will run w/ it for a day and if there are no other problems I would say it's a good patch.
btw, I did need to edit the returned patch file to be the following
--- src/mod_cgi.c (revision 612) +++ src/mod_cgi.c (revision 613) @@ -1127,12 +1127,7 @@ #ifndef __WIN32 switch(waitpid(hctx->pid, &status, WNOHANG)) { case 0: - /* not finished yet */ - if (con->file_started) { - return HANDLER_GO_ON; - } else { - return HANDLER_WAIT_FOR_EVENT; - } + return HANDLER_WAIT_FOR_EVENT; case -1: if (errno == EINTR) return HANDLER_WAIT_FOR_EVENT;
I needed to get the src/mod_cgi.c path cleaned up to work w/ what I had..
(minor adjustment)
-- Mystique
Updated by jan over 19 years ago
- Status changed from Assigned to Fixed
- Resolution set to fixed
two handlers were registrated and both have been called.
changeset r619 is fixing this.
Updated by jwmcglynn almost 18 years ago
- Status changed from Need Feedback to Fixed
- Resolution set to fixed
Fixed in r619, this bug shouldn't be reopened.
Also available in: Atom