I'd noticed that my 2.0.35 server would, within 15 minutes of starting, stop responding to HTTPS requests -- HTTP requests continue without a problem. Thinking this might have been resolved recently, I snagged a copy of the sources from CVS, compiled, and am getting the same result. In my SSLLog I saw references to mutex-related locking issues, as follows: -- [17/Apr/2002 00:30:32 14451] [info] Connection to child 13 established (server techbox.frognet.net:443, client 216.3.2.38) [17/Apr/2002 00:30:32 14451] [info] Seeding PRNG with 136 bytes of entropy [17/Apr/2002 00:30:32 14451] [warn] Failed to acquire global mutex lock [17/Apr/2002 00:30:32 14451] [warn] Failed to release global mutex lock -- I recompiled using the following: EXTRA_CFLAGS="-g" ./configure \ --enable-so \ --enable-ssl \ --disable-charset-lite \ --disable-negotiation && make .. set SSLLogLevel to debug, and tried different SSLMutex types, all with the same end result: within a few minutes of starting Apache stops responding to HTTPS requests but continues to serve HTTP. I'm on a Red Hat 7.2 box with OpenSSL 0.9.6b; I'll attach the SSLLog and gdb backtrace..
Created attachment 1602 [details] SSLLog (debug) and backtrace
Is this really 2.0.35, or is it 2.0.36-dev? I'm confused, because the backtrace you posted shows: #5 0x4003b548 in apr_global_mutex_lock () from /usr/local/apache2/lib/libapr.so.0 #6 0x08074023 in ssl_mutex_on (s=0x810e7e8) at ssl_engine_mutex.c:101 But ssl_mutex_on() called apr_lock_acquire() in 2.0.35 -- it wasn't changed to call apr_global_mutex_lock() until ssl_engine_mutex.c revision 1.13, which was post-2.0.35. http://cvs.apache.org/viewcvs.cgi/httpd-2.0/modules/ssl/ssl_engine_mutex.c.diff? r1=1.12&r2=1.13&sortby=date Any light you could shed on this would be appreciated... Thanks!
The backtrace attached, as you'd concluded, is from 2.0.36-dev. For reasons unknown (idiocy?), I'd assumed I was acquiring 2.0.35 via CVS.. my apolgies for the confusion. I've just compiled 2.0.35 (yes, 35) and cannot replicate the problem. The compile-time options selected, configuration files, etc. are identical, and I'm still seeing the "failed to acquire/release global mutex lock" in the error log, but the server hasn't stopped responding to HTTPS requests. I intend to perform more exhaustive testing in the morning.. Regards, Tom Howell-Cintron thc@frognet.net
I just noticed there's another PR dealing with this. A patch will be committed for 2.0.37 soon. *** This bug has been marked as a duplicate of 8124 ***