From Bugzilla Helper:
User-Agent: Mozilla/5.0 Galeon/1.1.3 (X11; Linux i686; U;) Gecko/20020205

Description of problem:
The eapi patch from mod_ssl is configured with -DEAPI_MM_CORE_PATH set to
/var/run, which is not a user-writable directory. This means that starting httpd
as a non-privileged user won't work, as httpd will try to  write a
"httpd.mm.xxxx.sem" file there.

Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1. log is as a normal user
2. run "/usr/sbin/httpd"
	

Actual Results:  Ouch! ap_mm_create(1048576, "/var/run/httpd.mm.3412") failed
Error: MM: mm:core: failed to open semaphore file (Permission denied): OS: No
such file or directory


Expected Results:  A normal user should be able to start httpd. Things should
fail here anyway here because I've not given a config file, but even with a
valid config, httpd will try to write in /var/run and die...

Additional info:

This is a nasty one, as it makes a common form of virtual hosting impossible:

1. Each customer runs it's own non-priviledged httpd on 127.0.0.1:portnum (where
portnum > 1024)
2. A normal httpd (or squid) runs as a front-end proxy to each of the customers'
httpds.

This bug is also present on RedHat 7.1

--------------  Workaround --------------

I've rebuilt the SRPM changing apache.spec as follows:

on line 91, changed:
CFLAGS="$RPM_OPT_FLAGS -fPIC
-DEAPI_MM_CORE_PATH='\"%{_localstatedir}/run/httpd.mm\"'" ; export CFLAGS

to:
CFLAGS="$RPM_OPT_FLAGS -fPIC
-DEAPI_MM_CORE_PATH='\"%{_localstatedir}/run/apache-mm/httpd.mm\"'" ; export CFLAGS

and creating a directory in /var/run :
drwxrwxrwt    2 root     root         4096 Mar 12 15:52 apache-mm

--------------------------------------------

The workaround allows normal users to run httpd. This works for us... 

Any ideas/suggestions?