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.
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.