Date: Sun, 25 Mar 2001 12:01:02 -0600 From: Mike Meyer <mwm@mired.org> To: "Ali Niknam" <ali@iephosting.net> Cc: questions@freebsd.org, dan@langille.org Subject: Re: Apache processes grind system to a halt Message-ID: <15038.12894.807851.555456@guru.mired.org> In-Reply-To: <93516798@toto.iv>
next in thread | previous in thread | raw e-mail | index | archive | help
Ali Niknam <ali@iephosting.net> 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. <mike > 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 > -- Mike Meyer <mwm@mired.org> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?15038.12894.807851.555456>