Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 25 Mar 2001 09:30:21 +1200
From:      "Dan Langille" <dan@langille.org>
To:        Christoph Sold <so@server.i-clue.de>
Cc:        questions@freebsd.org
Subject:   Re: Apache processes grind system to a halt
Message-ID:  <200103242130.f2OLUNf12850@ns1.unixathome.org>
In-Reply-To: <3ABB22A7.41E1D708@i-clue.de>

next in thread | previous in thread | raw e-mail | index | archive | help
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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200103242130.f2OLUNf12850>