On 5/22/2012 6:00 PM, Bill Unruh wrote:
> On Tue, 22 May 2012, William A. Rowe Jr. wrote:
> 
>> On 5/22/2012 12:02 PM, Bill Unruh wrote:
>>
>>> At that time in the access_log I have a whole bunch of entries like
>>> ::1 - - [22/May/2012:09:34:22 -0700] "OPTIONS * HTTP/1.0" 200 - "-" 
>>> "Apache/2.2.22
>>> (Mandriva Linux/PREFORK-0.1mdv2010.2) (internal dummy connection)"
>>
>> That's your own local loopback from a process running on this same box.
> 
> There are no processes running on this same box. It is rarely used. and
> certainly did not have a browser running at that time.

Then a server module is likely pinging itself.  Any chance you set up an 
infinite proxy
recursion here?

>>> In the past I have also had connections like 66.249.68.198 - - 
>>> [22/May/2012:09:35:25
>>> -0700] "GET
>>> /aggregator/www.umsl.edu/~keelr/010/www.twitter.com/www.iaea.org/Publications/Documents/Board/2008/www.environment-agency.gov.uk/homeandleisure/floods/node/www.guardian.co.uk/business/2012/feb/21/node/node/22?page=11
>>>
>>> HTTP/1.1" 200 58609 "-" "Mozilla/5.0 (compatible; Googlebot/2.1;
>>> +http://www.google.com/bot.html)"
>>
>> No clue.  Maybe playing with open proxies?  The document seems to be 58k if 
>> that helps you
>> at all (maybe a local index page?)
> 
> There is no such file or path on my system. If I try to use it, I get file not
> found. I have nothing called /aggregator/

Looking more and more like a proxy recursion/infinite looping sort of config 
error.

>> Can you interrupt one of the truly hosed processes using gdb and try 'thread 
>> apply all bt'
> 
> What does that do?

Dumps all threads instead of just one of them.

> Thread 1 (Thread 0xb760f700 (LWP 20861)):
> #0  0xffffe424 in __kernel_vsyscall ()
> #1  0xb77ece6b in fcntl () from /lib/i686/libpthread.so.0
> #2  0xb780f832 in ?? () from /usr/lib/libapr-1.so.0
> #3  0xb780f1ad in apr_proc_mutex_lock () from /usr/lib/libapr-1.so.0
> #4  0x0809294c in ?? ()
> #5  0x08092e0b in ?? ()
> #6  0x08093be4 in ap_mpm_run ()
> #7  0x08064cd1 in main ()

It might be helpful to first install the debuginfo for the apr/httpd packages, 
but this
looks like it might be in the accept queue waiting on the MutexFile to unblock 
this one
(and is probably a healthy process).

If you are running prefork we would encourage you to try the worker mpm.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org

Reply via email to