Hello.

I have just posted something similar on the httpd-users mailing list but I'm not sure if it's an apache problem or redhat problem.

My apache error_log is telling me

Cannot allocate memory: Unable to create scoreboard (anonymous shared
memory failure)

when trying to restart apache/2.0.52 after I had to hard reboot my redhat9 box. I had to do a manual fsck and just took the default option for whatever came up.

I came across this website

hacksaw.ca/2004/12/failure-restarting-apache-http-server.html

which suggests I use the

ipcs -m -p

command but no processes or segments are being listed for me to remove.

Is there some other command I can use to try and get rid of this shared memory failure?

Thanks,

D.

I just want to clarify that the output for ipcs -m -p

------ Shared Memory Creator/Last-op --------
shmid owner cpid lpid


and if I try ipcs -m I get


------ Shared Memory Segments --------
key shmid owner perms bytes nattch status


If there is no command I can use is there somewhere in the file system I can go and delete whatever it is preventing me from starting apache?

If you just did a hard reboot, why can't you do another one?
As the website suggests, the trick with the ipcs command is only to be used if you don't want to
reboot your machine.
If you hard reboot it, the shared memory should be de-allocated anyway, unless it was dumped to a file on disk.

I did a hard reboot which caused no end of problems. I had to repeatedly run fsck before eventually being able to log in.
Unfortunately, I still have the same problem i.e.

(22)Invalid argument: unable to create scoreboard "/var/run/apache.scoreboard" (name-based shared memory failure)

if a specify a scoreboard in httpd.conf

or

(12)Cannot allocate memory: Unable to create scoreboard (anonymous shared memory failure)

if I comment out the scoreboard directive in the httpd.conf

Hmmm. After a hard reboot, all shared memory should have been cleaned up anyway.

By the way, you shouldn't use a file on disk to store the scoreboard data. Shared memory is faster.

If ipcs (run as root) doesn't mention the shared memory, then your process doesn't have access to it, or, more likely, it simply doesn't exist. A hard reboot should have cleaned it up, so it can be normal that ipcs doesn't list it anymore.
However, even on systems that don't have Apache running (like my simple RH8 box), ipcs -m still lists a bunch of stuff from other programs. The fact that your ipcs doesn't indicate anything at all, may point to a different problem, not specific for Apache, but for all processes who use shared memory.

A few questions:
-Can you try an ls -l of /var/run and /var/run/apache?
-Did you recently change anything to your system configuration, such as updates of the C libraries, etc?
-Are you absolutely sure that you ran the ipcs command under the root user?
-Can you please look at the other system logs in /var/log. Maybe there's an indication of a larger problem.
-What did fsck report back to you? And what did it fix, in order for your login to succeed?

Finally, I've read on a site that you could take a look at some pseudo-files in /proc, such as /proc/self/maps, but they're probably hard to understand.