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-unsubscribe@xxxxxxxxxxxxxxxx For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
|