Andre, this can be fixed with the attached patch for several cases, I believe.
First, cvs up to the latest apr library sources, because I've fixed the proc_mutex (and therefore the global_mutex) to; 1. use the res_name_from_filename folding function - this assures we quietly accept slashes and such as underbars in the mutex names. 2. happily return APR_SUCCESS and not try to reopen the mutex in our mutex_init_child functions, if no mutex name was given. The attached patch will update Jim's latest changes to SSLMutex to accept a filename argument for all mutex types, including default:foo. So Win32 should now work with default or default:foo. The patch also removes the modssl.org random filenames within the SSLMutex directive, so that we *accept* the exact name given by the user. This allows named mutexes to be used between processes on Win32 or other platforms that don't maintain the same pid between parent and child processes (e.g. non-fork.) We treat the poxissem: method (or sem: method when SysV is missing) as a literal name, all others will be "rooted" to the current drive, so that /apache2/logs/sslmutex differs from /apache2.1/logs/sslmutex, or however one organizes concurrent installations of Apache. The code should be infinitely more readable after the patch. I need three +1's from careful reviewers before adopting for 2.0.45 and eliminating this hassle. Without this patch, Win32 will have a 'default' mutex, but it won't be the same from generation to generation (it is unnamed.) With this patch, we will have a shared mutex across win32 children, so that graceful restarts won't corrupt the sessioncache. Without this patch, the errors still go away with the latest update, but we don't use a common mutex between win32 children. Finally, I consider the current ssl.conf.in line SSLMutex file::logs/ssl_mutex to be somewhat bogus, I would think that SSLMutex default:logs/ssl_mutex is more appropriate. Bill At 02:31 PM 3/26/2003, Andre Schild wrote: >Hello, > >I did some investigations on this message and found the following: > >Using SSLMutex default results in no-filename for the mutex. > In the comments to this, there it stays: > mc->szMutexFile = NULL; /* APR determines temporary filename */ > >According to the apr documentation (and the win32 implementation it >doesnt) > * @param fname A file name to use if the lock mechanism requires one. >This > * argument should always be provided. The lock code itself >will > * determine if it should be used. > > >As for a solution to this problems my suggestions: > >We should initialize the mutexfilename with something "unique" in >ssl_engine_config.c > >Instead of: > mc->szMutexFile = NULL; /* APR determines temporary filename */ > >Proposition: > mc->szMutexFile = apr_psprintf(mc->pPool, "%s.%lu", > "Apache_OPENSSLMutex", (unsigned long)getpid()); > >Sidenote: > >The win32 implementations of apr_proc_mutex_create and >apr_proc_mutex_child_init >don't generate a error or print a warning when the (required) >parameter >fname is NULL. >Would be nice if the APR notified this as an error...... > > >Andr� > >>>> [EMAIL PROTECTED] 25.03.2003 23:39:17 >>> >William A. Rowe, Jr. schrieb: > >>At 02:20 PM 3/25/2003, Andr� Schild wrote: >> >> >>>William A. Rowe, Jr. schrieb: >>> >>> >>> >>>>Apache 2.0 testers, >>>> >>>>can you please help move forward the next HTTPD release by >>>>checking out httpd-2.0 from the WROWE_2_0_45_RC1 tag? >>>> >>>> >>>The SSLMutex always creates this message in the error log on the >first access >>>with a HTTPS request: >>> >>>[Tue Mar 25 21:04:55 2003] [warn] (OS 123)Die Syntax f�r den >Dateinamen, Verzeichnisnamen oder die Datentr�gerbezeichnung ist falsch. > : Cannot reinit SSLMutex >>> >>> >> >>I got the message from it's number (thank goodness we finally group >>these by 'role') - and I'm diagnosing now. >> >> >There is a small error in my previous mail. >Of course I use the > >SSLMutex default > >config entry, as on win32 you only have the choice between none and >default. > >I'm using openssl 0.9.7a and MS dev studio 6.0 > >Andr�
