Bug 8124 - mod_ssl fails to get and release semaphore mutex
Summary: mod_ssl fails to get and release semaphore mutex
Alias: None
Product: Apache httpd-2
Classification: Unclassified
Component: mod_ssl (show other bugs)
Version: 2.0.36
Hardware: PC other
: P3 normal with 5 votes (vote)
Target Milestone: ---
Assignee: Apache HTTPD Bugs Mailing List
: 8186 8890 8930 (view as bug list)
Depends on:
Reported: 2002-04-15 19:36 UTC by Martin Kutschker
Modified: 2004-11-16 19:05 UTC (History)
4 users (show)

improved error reporting (3.06 KB, patch)
2002-05-06 16:50 UTC, Martin Kutschker
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Martin Kutschker 2002-04-15 19:36:32 UTC
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.
Comment 1 Andreas Hasenack 2002-04-16 14:05:51 UTC
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?
Comment 2 Martin Kutschker 2002-04-16 14:28:38 UTC
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.
Comment 3 Martin Kutschker 2002-05-06 16:50:03 UTC
Created attachment 1793 [details]
improved error reporting
Comment 4 Martin Kutschker 2002-05-06 16:53:54 UTC
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.
Comment 5 Cliff Woolley 2002-05-06 16:54:55 UTC
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.   
Comment 6 Cliff Woolley 2002-05-07 22:42:34 UTC
*** Bug 8186 has been marked as a duplicate of this bug. ***
Comment 7 Cliff Woolley 2002-05-07 22:42:58 UTC
*** Bug 8890 has been marked as a duplicate of this bug. ***
Comment 8 Cliff Woolley 2002-05-09 04:29:22 UTC
*** Bug 8930 has been marked as a duplicate of this bug. ***
Comment 9 Cliff Woolley 2002-05-09 05:22:56 UTC
this problem still exists in 2.0.36, so I'm updating the version number
Comment 10 Justin Erenkrantz 2002-05-13 08:28:20 UTC
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!
Comment 11 Andreas Sundstr 2002-05-13 14:12:12 UTC
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
Comment 12 Jeff Trawick 2002-05-14 13:27:32 UTC
Justin committed a fix for this problem on May 13; it will be in the
next release of Apache 2.0.
Comment 13 Martin Kutschker 2002-05-14 14:27:38 UTC
Is there a reason why the fix does not include my little patch for error reporting?

Otherwise, thanx for the fix.
Comment 14 Jeff Trawick 2002-05-14 14:37:46 UTC
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.