From owner-freebsd-questions Sun Mar 25 10: 1:12 2001 Delivered-To: freebsd-questions@freebsd.org Received: from guru.mired.org (okc-65-26-235-186.mmcable.com [65.26.235.186]) by hub.freebsd.org (Postfix) with SMTP id 48C4D37B719 for ; Sun, 25 Mar 2001 10:01:04 -0800 (PST) (envelope-from mwm@mired.org) Received: (qmail 28352 invoked by uid 100); 25 Mar 2001 18:01:02 -0000 From: Mike Meyer MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15038.12894.807851.555456@guru.mired.org> Date: Sun, 25 Mar 2001 12:01:02 -0600 To: "Ali Niknam" Cc: questions@freebsd.org, dan@langille.org Subject: Re: Apache processes grind system to a halt In-Reply-To: <93516798@toto.iv> X-Mailer: VM 6.89 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid X-face: "5Mnwy%?j>IIV\)A=):rjWL~NB2aH[}Yq8Z=u~vJ`"(,&SiLvbbz2W`;h9L,Yg`+vb1>RG% *h+%X^n0EZd>TM8_IB;a8F?(Fb"lw'IgCoyM.[Lg#r\ Sender: owner-freebsd-questions@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Ali Niknam types: > Hi All, > I personally think a rewrite may have caused it - it's really unsafe to > allow ppl rewriting rules.... When my own server was up & running (but not > used yet) I tried some voodoo-magic-rewriting too :) What I found out (what > probably is well known) is that you can make an endless rewrite loop... > (so that one directory sends the thing to another and the other sends it > back) Well, that's not the only thing that can cause it. I've got a server with similar problems, with no rewrite rules in the config file. In fact, there's no rewrite module in the binary. I was surprised to see that this brought apache and the server with it to > its knees... At the time I was running Linux 2.2.18 (as I said I was just > fooling around - ofcourse I'm running FreeBSD 4.2-Stable now :) and it > really wasn't healthy for the machine... > > I killed the processes before it was too late and recompiled apache without > mod_rewrite... that helped :) > > You ofcourse understand that customers are nagging to get it :) There must > be a solution somewhere. > > Grtz, > Ali > > ----- Original Message ----- > From: "Dan Langille" > To: "Christoph Sold" > Cc: > Sent: Saturday, March 24, 2001 10:30 PM > Subject: Re: Apache processes grind system to a halt > > > > On 23 Mar 2001, at 11:17, Christoph Sold wrote: > > > > > Dan Langille schrieb: > > > > > > > > About 2 or 3 times a day, Apache gets its knickers in a twist. > Sometimes it takes > > > > the box down with it. If left unchecked, the load averages climb, > swap is > > > > exhausted, and the system dies. If I keep an eye on the box and > kill -TERM the > > > > processes, the box is OK. But that is not a solution. > > > > > > > > I have no idea why Apache does this. The web server is running > Apache, php, > > > > mysql. This may be a php script out of control, but if it is, I don't > know how to > > > > find it. The box is running 4.2-stable. Apache, php, and mysql are > recent > > > > versions (all upgraded yesterday in case that was the problem). > > > > > > > > Is there a way to determine what a particular httpd process is doing? > At least > > > > then I could see what task was taking so much time. > > > > > > If server-status and server-info modules are compiled in, you may get > > > some hints. Look at http://your.server.name/server-status rsp. > > > server-info. If you get nothing, enable them in your apache config file. > > > > > > Server-status tells which child does what (i.e. idle, waiting for > > > response from cgi, delivering answer...) as well as the URL which caused > > > the action. > > > > > > Server-info tells exactly which configuration is running, as well as > > > listing the options as apache has seen them during startup. Helps > > > debugging the config file. > > > > When I started this process, my first step was to upgrade to the latest > > versions of php, apache, DBI, etc... That didn't solve the problem. > > > > During the analysis of the problem, I used server-info, server-status, and > > ktrace. It turn out ktrace showed me the information I needed. > > kdumpm kept showing these things: > > > > > > 381 httpd CALL break(0xa2f6000) > > 381 httpd RET break 0 > > 381 httpd CALL break(0xa2f9000) > > 381 httpd RET break 0 > > 381 httpd CALL break(0xa2fc000) > > 381 httpd RET break 0 > > 381 httpd CALL break(0xa2ff000) > > 381 httpd RET break 0 > > 381 httpd CALL break(0xa302000) > > 381 httpd RET break 0 > > the above two lines repeat about 22 times with different values for break. > > 381 httpd CALL stat(0xa2ff6a0,0xa273a38) > > 381 httpd NAMI "/www/freshports.org/spambots.html" > > 381 httpd RET stat 0 > > 381 httpd CALL break(0xa305000) > > 381 httpd RET break 0 > > > > It was the spambots bit which gave me a clue. This led me to the > > following within the FreshPorts VirtualHost in the Apache configuration > > file: > > > > RewriteCond %{HTTP_USER_AGENT} ^EmailSiphon [OR] > > RewriteCond %{HTTP_USER_AGENT} ^EmailWolf [OR] > > RewriteCond %{HTTP_USER_AGENT} ^ExtractorPro [OR] > > RewriteCond %{HTTP_USER_AGENT} ^Mozilla.*NEWT [OR] > > RewriteCond %{HTTP_USER_AGENT} ^Crescent [OR] > > RewriteCond %{HTTP_USER_AGENT} ^CherryPicker [OR] > > RewriteCond %{HTTP_USER_AGENT} ^[Ww]eb[Bb]andit [OR] > > RewriteCond %{HTTP_USER_AGENT} ^WebEMailExtrac.* [OR] > > RewriteCond %{HTTP_USER_AGENT} ^NICErsPRO [OR] > > RewriteCond %{HTTP_USER_AGENT} ^Telesoft [OR] > > RewriteCond %{HTTP_USER_AGENT} ^Microsoft.URL [OR] > > RewriteCond %{HTTP_USER_AGENT} ^Mozilla/3.Mozilla/2.01 [OR] > > RewriteCond %{HTTP_USER_AGENT} ^EmailCollector > > RewriteRule ^.*$ /spambots.html [L] > > > > I disable all such rewrites from the Apache configuration file. It's been > > about 36 hours since I did this. There have been no runaway processes > > at all. It may be too early to call this a solution, but the situation > will be > > closely monitored for a while. > > > > I'd still like to know if the rewrite was the cause, and if so why it > caused > > such a problem. > > > > Thanks folks. > > > > -- > > Dan Langille > > pgpkey - finger dan@unixathome.org | http://unixathome.org/finger.php > > got any work? I'm looking for some. > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-questions" in the body of the message > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-questions" in the body of the message > -- Mike Meyer http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message