Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Message-ID: <3F5BB643.3030205@attglobal.net>
Date: Sun, 07 Sep 2003 18:50:43 -0400
From: Jeff Trawick <trawick@attglobal.net>
Reply-To: trawick@attglobal.net
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
 rv:1.4) Gecko/20030624
MIME-Version: 1.0
To: Anthony Howe <achowe@snert.com>, dev@apr.apache.org, dev@httpd.apache.org
Subject: Re: apr_global_mutex_child_init & mod_watch
References: <3F5B53C8.3010500@snert.com> <3F5B58B3.7040901@attglobal.net>
 <3F5B5E03.4010604@snert.com> <3F5B7406.2040808@attglobal.net>
 <3F5B7AC1.2070209@snert.com>
In-Reply-To: <3F5B7AC1.2070209@snert.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Anthony Howe wrote:

> [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 dev@httpd 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)