Summary: | if apache doesn't start cleanly - SSL fails to start EVER (until after reboot) | ||
---|---|---|---|
Product: | Apache httpd-2 | Reporter: | Klavs Klavsen <kl> |
Component: | mod_ssl | Assignee: | Apache HTTPD Bugs Mailing List <bugs> |
Status: | RESOLVED FIXED | ||
Severity: | critical | CC: | black, mblack |
Priority: | P3 | ||
Version: | 2.0.46 | ||
Target Milestone: | --- | ||
Hardware: | PC | ||
OS: | Linux |
Description
Klavs Klavsen
2003-07-04 07:02:34 UTC
1) stray semaphores don't affect whether or not Apache can allocate shared memory Doesn't ipcs show some shared memory owned by the user that started Apache? See if deleting that will allow Apache to start again. 2) cleaning up those stray semaphores: The command to remove the sem is "ipcrm sem ###", such as ipcrm sem 32768 Also, you have to do this as a user with the proper permissions. Yeah, this stuff is bad, the APR shm code is more _EXCL-happy than MM was. I've got a change to mod_ssl to make it use anon shm by default and fall back on file-based which makes most of these problems go away on modern platforms. I'm getting this loads of times on HPUX 11i using Apache 2.0.48 mod_perl 0.9_10. It seems to happen whenever you do a graceful and sometimes removing the shared memory using ipcs does not work, you have to remove the whole /logs directory (where ever ssl_scache is being stored). Is there an ETA for a fix on this? If you use "SSLMutex default", and the shmcb session cache with this fix applied: http://cvs.apache.org/viewcvs.cgi/httpd-2.0/modules/ssl/ssl_scache_shmcb.c?r1=1.23&r2=1.24 I think that avoids the problems. *** Bug 29177 has been marked as a duplicate of this bug. *** *** Bug 30147 has been marked as a duplicate of this bug. *** I don't think this issue remains in current 2.2.x releases, possibly not even 2.0.x. |