Date: Sun, 25 Mar 2001 00:08:32 +0100 From: "Ali Niknam" <ali@iephosting.net> To: <dan@langille.org>, "Christoph Sold" <so@server.i-clue.de> Cc: <questions@freebsd.org> Subject: Re: Apache processes grind system to a halt Message-ID: <001201c0b4b7$5909c040$0100a8c0@cow> References: <200103242130.f2OLUNf12850@ns1.unixathome.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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) 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" <dan@langille.org> To: "Christoph Sold" <so@server.i-clue.de> Cc: <questions@freebsd.org> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?001201c0b4b7$5909c040$0100a8c0>