On my Linux (RedHat 7.2) mod_ssl logs an error whenever it tries to access a system v semaphore based mutex. For whatever reason, it does not complain when creating the mutex. It looks like a permission problem to me (I added error number reporting to mod_ssl), but I don't know why. Apache itself creates the shared mem and the semaphores as root and nobody with the permissions set to 600. After forcing file based locking by hacking(see bug #8122) the errors disappeared.
Probably related to these log messages I'm seeing in my logs (linux) whenever an SSL connection comes in: [16/Apr/2002 10:30:07 19876] [warn] Failed to acquire global mutex lock [16/Apr/2002 10:30:07 19876] [warn] Failed to release global mutex lock No mutex file shows up in the log dir. What exactly are the consequences of this warning I see in the logs?
Andreas, mod_ssl does never user file based locking due to bug #8122, so no file will show up. The warnings imply that mod_ssl is not using lock, so it's like saying "SSLMutex none". My theory is that Apache creates the semaphores and THEN switches user/group locking mod_ssl out of shm/sem.
Created attachment 1793 [details] improved error reporting
The attachment adds apr_sterror output to the mutex functions. They will report "Permission denied errors" for acquiring and releasing. These changes are included in my patch for bug #8122.
The problem is that the permissions on the sysv semaphore are set wrong. This is the same PR8143, except in a different module. (PR8143 is mod_rewrite, but the same thing is happening.) A general fix for this is in the works.
*** Bug 8186 has been marked as a duplicate of this bug. ***
*** Bug 8890 has been marked as a duplicate of this bug. ***
*** Bug 8930 has been marked as a duplicate of this bug. ***
this problem still exists in 2.0.36, so I'm updating the version number
Based on Aaron's patch to mod_rewrite, I have committed a temporary fix for this problem into CVS. Can you please try the latest version from CVS and see if it is fixed now? Thanks for using Apache!
It looks like it works fine for me :) No more [warn] Failed to acquire global mutex lock [warn] Failed to release global mutex lock in ssl_engine_log either
Justin committed a fix for this problem on May 13; it will be in the next release of Apache 2.0.
Is there a reason why the fix does not include my little patch for error reporting? Otherwise, thanx for the fix.
As for why the patch for error reporting wasn't committed: What is needed is for ssl_log() function to be changed to allow an optional apr_status_t error code to be passed in. Alternatively, a new ssl_log_error() function could be created which allows an apr_status_t error code to be passed in. Either way, callers don't have to worry about formatting the apr_strerror() string or the apr_status_t error code. I'll try to get a discussion started on dev@httpd.apache.org to see what is the preferable way to get the diagnostics logged. Thanks...