Bug 21335 - if apache doesn't start cleanly - SSL fails to start EVER (until after reboot)
Summary: if apache doesn't start cleanly - SSL fails to start EVER (until after reboot)
Status: RESOLVED FIXED
Alias: None
Product: Apache httpd-2
Classification: Unclassified
Component: mod_ssl (show other bugs)
Version: 2.0.46
Hardware: PC Linux
: P3 critical (vote)
Target Milestone: ---
Assignee: Apache HTTPD Bugs Mailing List
URL:
Keywords:
: 29177 30147 (view as bug list)
Depends on:
Blocks:
 
Reported: 2003-07-04 07:02 UTC by Klavs Klavsen
Modified: 2014-02-17 13:59 UTC (History)
2 users (show)



Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Klavs Klavsen 2003-07-04 07:02:34 UTC
I keep having this problem, that when ever I restart apache, and the start fails
(f.ex. because I'm testing a php-module that doesn't work),
apache won't start afterwards. It complains about File exists(17): Cannot
allocate shared memory.

I remove the ssl_scache file - so that's not it - I belive it's these 

ipcs -a | grep apache

------ Semaphore Arrays --------
key        semid      owner      perms      nsems
0x00000000 32768      apache    600        1
0x00000000 2490434    apache    600        1
0x00000000 2555971    apache    600        1
0x00000000 2621508    apache    600        1

I tried to remove them, but ipcrm sem 1 
said, cannot remove id.

It's that annoying SSL that breaks EVERY time I try something and apache won't
start. when I fix it, and apache won't start due to this annoying SSL problem.

This has NEVER been there with mod_ssl and apache1 - and I've done this in many
years.
Comment 1 Jeff Trawick 2003-07-10 15:23:59 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.
Comment 2 Joe Orton 2003-07-10 20:59:21 UTC
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. 
Comment 3 John Rush 2004-03-07 09:00:03 UTC
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?
Comment 4 Joe Orton 2004-03-07 18:37:23 UTC
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.
Comment 5 Joe Orton 2004-05-25 08:23:09 UTC
*** Bug 29177 has been marked as a duplicate of this bug. ***
Comment 6 Joe Orton 2004-07-19 10:15:34 UTC
*** Bug 30147 has been marked as a duplicate of this bug. ***
Comment 7 Joe Orton 2011-02-12 09:52:25 UTC
I don't think this issue remains in current 2.2.x releases, possibly not even 2.0.x.