Bug 8890 - ssl stop serving pages after a couple of minutes
Summary: ssl stop serving pages after a couple of minutes
Status: CLOSED DUPLICATE of bug 8124
Alias: None
Product: Apache httpd-2
Classification: Unclassified
Component: mod_ssl (show other bugs)
Version: 2.0.36
Hardware: PC Linux
: P3 normal (vote)
Target Milestone: ---
Assignee: Apache HTTPD Bugs Mailing List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2002-05-07 20:59 UTC by Andreas Sundstr
Modified: 2004-11-16 19:05 UTC (History)
0 users



Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Andreas Sundstr 2002-05-07 20:59:05 UTC
I have reproduced this on 3 different computers running Linux kernel >=2.4.17
glibc >=2.2.4
It works for some time then suddenly it stops working and never seems to work
again, the process doesn't seem to be hanged, no 100% cpu load.

I'm not used to debug stuff so please let me know if I can contribute with more
info here's what I think is useful..

apache is configured with:
CFLAGS="" ./configure --prefix=/opt/apache --enable-ssl --enable-maintainer-mode

sunkan:# tail /opt/apache/logs/ssl_engine_log
[07/May/2002 22:33:42 23203] [info]  Subsequent (No.7) HTTPS request received
for child 6 (server new.host.name:443)
[07/May/2002 22:33:42 23203] [info]  Subsequent (No.8) HTTPS request received
for child 6 (server new.host.name:443)
[07/May/2002 22:33:57 23203] [info]  Connection to child 6 closed with standard
shutdown(server new.host.name:443, client ::1)
[07/May/2002 22:34:21 23195] [info]  Connection to child 1 established (server
new.host.name:443, client ::1)
[07/May/2002 22:34:21 23195] [info]  Seeding PRNG with 136 bytes of entropy
[07/May/2002 22:34:21 23195] [warn]  Failed to acquire global mutex lock
[07/May/2002 22:34:21 23195] [warn]  Failed to release global mutex lock
sunkan:#

sunkan:# /opt/apache/bin/httpd -V
Server version: Apache/2.0.36
Server built:   May  7 2002 22:21:25
Server's Module Magic Number: 20020329:1
Architecture:   32-bit
Server compiled with....
 -D APACHE_MPM_DIR="server/mpm/prefork"
 -D APR_HAS_SENDFILE
 -D APR_HAS_MMAP
 -D APR_HAVE_IPV6
 -D APR_USE_SYSVSEM_SERIALIZE
 -D APR_USE_PTHREAD_SERIALIZE
 -D SINGLE_LISTEN_UNSERIALIZED_ACCEPT
 -D APR_HAS_OTHER_CHILD
 -D AP_HAVE_RELIABLE_PIPED_LOGS
 -D HTTPD_ROOT="/opt/apache"
 -D SUEXEC_BIN="/opt/apache/bin/suexec"
 -D DEFAULT_ERRORLOG="logs/error_log"
 -D SERVER_CONFIG_FILE="conf/httpd.conf"

When the server stops serving ssl pages I used this method to try and find out
which process is responsible for that connection.

sunkan:# netstat -anp|grep ht
tcp        0      0 :::80                   :::*                    LISTEN     
23193/httpd         
tcp        0      0 :::443                  :::*                    LISTEN     
23193/httpd         
tcp      645      0 ::1:443                 ::1:32969               ESTABLISHED
23195/httpd         

sunkan:# gdb /opt/apache/bin/httpd 23195
0x402aa815 in sigsuspend () from /lib/libc.so.6
(gdb) bt
#0  0x402aa815 in sigsuspend () from /lib/libc.so.6
#1  0x4026fd8b in __pthread_wait_for_restart_signal () from /lib/libpthread.so.0
#2  0x402714bb in __pthread_alt_lock () from /lib/libpthread.so.0
#3  0x4026e895 in pthread_mutex_lock () from /lib/libpthread.so.0
#4  0x40047143 in apr_thread_mutex_lock (mutex=0x8130780) at thread_mutex.c:149
#5  0x40045ae2 in apr_global_mutex_lock (mutex=0x81306f8) at global_mutex.c:130
#6  0x0807b01f in ssl_mutex_on (s=0x8131e40) at ssl_engine_mutex.c:101
#7  0x080818f1 in ssl_scache_dbm_store (s=0x8131e40, id=0x8174ff8 "\035@z���\203
\203�0*�c�5\f��\232��\227�\177����L\e\036� ", idlen=32, expiry=1020803961,
sess=0x8174fb0) at ssl_scache_dbm.c:172
#8  0x08081184 in ssl_scache_store (s=0x8131e40, id=0x8174ff8 "\035@z���\203
\203�0*�c�5\f��\232��\227�\177����L\e\036� ", idlen=32, expiry=1020803961,
sess=0x8174fb0) at ssl_scache.c:127
#9  0x0807a0cf in ssl_callback_NewSessionCacheEntry (ssl=0x813f5e8,
session=0x8174fb0) at ssl_engine_kernel.c:1717
#10 0x400daf7c in ssl_update_cache () from /usr/lib/libssl.so.0.9.6
Cannot access memory at address 0x3
(gdb)
Comment 1 Cliff Woolley 2002-05-07 22:40:37 UTC
We've already been working on this issue.  A patch will be committed for 2.0.37 soon. 
Comment 2 Cliff Woolley 2002-05-07 22:42:57 UTC

*** This bug has been marked as a duplicate of 8124 ***