[Sun Sep 07 20:18:07 2003] [crit] (13)Permission denied: apr_global_mutex_child_init(8111428, /var/lib/mod_watch/SharedHash.lock, 81a5018) failed in shChildInit()
EPERM is better :) I was so confused about the EGENERAL before
Its as though
unixd_set_global_mutex_perms((apr_global_mutex_t *) tp->mutex);
is broken such that the child process changes ownership then can't access the mutexes that were created 0600 I presume. I touched on this and a similar shared memory issue way back and it would appear to still be an open bug:
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16056
Now I'm assuming that on FreeBSD the SystemV mutexes are being used. I didn't see where this is determined in the configuration so I can't be certain, but I bet if I changed the permissions from 0600 to 0660 for the mutex and made sure the group are set correctly then it may work.
flock is used on FreeBSD by default... flock requires that chmod be done on the lock in the child init
if you look at Apache 2.1-dev, unixd_set_global_mutex_perms() has been changed to handle the chmod() for you
at Apache 2.0.48-dev, you have to do the chmod() on the lock file, like mod_ssl does in that branch
this is a situation where mod_rewrite wasn't a great place to look since mod_rewrite never handled this situation correctly in 2.0, and I fixed mod_rewrite in 2.1-dev by teaching unixd_set_global_mutex_perms() to be smarter... unfortunately, the change has not yet been merged into the stable tree
so you can figure out what kind of mutex it is and, if it is fcntl, do the chmod() yourself, or hope that 2.0 is changed to handle this issue for you
I've copied [EMAIL PROTECTED] to nag about getting the unixd_set_global_mutex_perms() enhancement (doing the right thing with flock mutexes) merged into stable finally.
(btw, please let's keep this on the mailing list(s)... you may have to hit "ReplyAll" or some such button in your e-mail client to make that happen)
