You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Jeff Trawick <tr...@attglobal.net> on 2003/09/08 00:50:43 UTC
Re: apr_global_mutex_child_init & mod_watch
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)
Re: apr_global_mutex_child_init & mod_watch
Posted by Anthony Howe <ac...@snert.com>.
> 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
Looking at the SSL code for this aspect, I noticed that mod_ssl will
pass NULL with APR_LOCK_DEFAULT, which means that it never sets
mc->ChownMutexFile to TRUE and relies on either:
apr_global_mutex_create()
unixd_set_global_mutex_perms()
to chown the lockfile. I've not looked at the code for those two
functions, but empirical testing yesterday showed that passing NULL for
the lock file and APR_LOCK_DEFAULT to apr_global_mutex_create() will
cause an EPERM error later in apr_global_mutex_child_init().
So it looks to me that mod_ssl's solution is NOT 100% reliable in the
current version of Apache when APR_LOCK_DEFAULT is used.
By the way mod_digest will also have similar problems with mutexes as
mod_rewrite.
--
Anthony C Howe +33 6 11 89 73 78
http://www.snert.com/ ICQ: 7116561 AIM: Sir Wumpus
" " - Zen thought
Re: apr_global_mutex_child_init & mod_watch
Posted by Anthony Howe <ac...@snert.com>.
> 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
Looking at the SSL code for this aspect, I noticed that mod_ssl will
pass NULL with APR_LOCK_DEFAULT, which means that it never sets
mc->ChownMutexFile to TRUE and relies on either:
apr_global_mutex_create()
unixd_set_global_mutex_perms()
to chown the lockfile. I've not looked at the code for those two
functions, but empirical testing yesterday showed that passing NULL for
the lock file and APR_LOCK_DEFAULT to apr_global_mutex_create() will
cause an EPERM error later in apr_global_mutex_child_init().
So it looks to me that mod_ssl's solution is NOT 100% reliable in the
current version of Apache when APR_LOCK_DEFAULT is used.
By the way mod_digest will also have similar problems with mutexes as
mod_rewrite.
--
Anthony C Howe +33 6 11 89 73 78
http://www.snert.com/ ICQ: 7116561 AIM: Sir Wumpus
" " - Zen thought
Re: apr_global_mutex_child_init & mod_watch
Posted by Jeff Trawick <tr...@attglobal.net>.
Anthony Howe wrote:
>> 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
>
>
> You mean chown() right? Or do you mean both chmod() and chown()?
oops, I meant chown()... maybe you want to have a look at unixd.c
(http://cvs.apache.org/viewcvs.cgi/httpd-2.0/os/unix/unixd.c?annotate=1.58)
to see special handling required for flock and sysvsem mutexes...
Re: apr_global_mutex_child_init & mod_watch
Posted by Anthony Howe <ac...@snert.com>.
> 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
You mean chown() right? Or do you mean both chmod() and chown()?
> at Apache 2.0.48-dev, you have to do the chmod() on the lock file, like
> mod_ssl does in that branch
Actually I did chown(), not a chmod() and everything worked on FreeBSD.
The lockfile was create with 0600 permissions already:
#if defined(__unix__)
/* Set the lockfile ownership, if it exists. This will eventually be
* handled by unixd_set_global_mutex_perms() in Apache 2.1 and maybe
* 2.0.48 (but I won't count on it).
*/
if (chown(tp->lockfile, unixd_config.user_id,
unixd_config.group_id) && errno != 0 && errno != ENOENT) {
ap_log_error(...);
unixd_set_global_mutex_perms((apr_global_mutex_t *) tp->mutex);
#endif
Next Linux testing...
--
Anthony C Howe +33 6 11 89 73 78
http://www.snert.com/ ICQ: 7116561 AIM: Sir Wumpus
" " - Zen thought
Re: apr_global_mutex_child_init & mod_watch
Posted by Anthony Howe <ac...@snert.com>.
> 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
You mean chown() right? Or do you mean both chmod() and chown()?
> at Apache 2.0.48-dev, you have to do the chmod() on the lock file, like
> mod_ssl does in that branch
Actually I did chown(), not a chmod() and everything worked on FreeBSD.
The lockfile was create with 0600 permissions already:
#if defined(__unix__)
/* Set the lockfile ownership, if it exists. This will eventually be
* handled by unixd_set_global_mutex_perms() in Apache 2.1 and maybe
* 2.0.48 (but I won't count on it).
*/
if (chown(tp->lockfile, unixd_config.user_id,
unixd_config.group_id) && errno != 0 && errno != ENOENT) {
ap_log_error(...);
unixd_set_global_mutex_perms((apr_global_mutex_t *) tp->mutex);
#endif
Next Linux testing...
--
Anthony C Howe +33 6 11 89 73 78
http://www.snert.com/ ICQ: 7116561 AIM: Sir Wumpus
" " - Zen thought
Re: apr_global_mutex_child_init & mod_watch
Posted by Jeff Trawick <tr...@attglobal.net>.
Anthony Howe wrote:
>> flock is used on FreeBSD by default... flock requires that chmod be
>> done on the lock in the child init
>
>
> As an aside, why is flock() used on FreeBSD?
historical reasons?
>> at Apache 2.0.48-dev, you have to do the chmod() on the lock file,
>> like mod_ssl does in that branch
>
>
> OK. Is there an API that returns what the APR_LOCK_DEFAULT mutex will be?
not exactly, but there is an API that will give you the info you need:
apr_proc_mutex_name(); pass it a mutex and it returns a string such as
"sysvsem", "flock", "fcntl", etc. to indicate what mechanism is in use
alternatively, if APR_USE_FLOCK_SERIALIZE is defined in apr.h then the
default is flock
> That would be the ideal solution, but I'm not sure I can wait until
> 2.0.48. Plus not everyone upgrades when they should, so I need a work
> around.
probably won't be in 2.0.48 anyway
> BTW are there any version macros in Apache 2 or the APR like:
>
> APACHE_VERSION_MAJOR
> APACHE_VERSION_MINOR
see ap_release.h for similar
> APR_VERSION_MAJOR
> APR_VERSION_MINOR
see apr_version.h for similar
Re: apr_global_mutex_child_init & mod_watch
Posted by Anthony Howe <ac...@snert.com>.
> flock is used on FreeBSD by default... flock requires that chmod be
> done on the lock in the child init
As an aside, why is flock() used on FreeBSD? It has SysV like mutexes
and POSIX ones too (at least in 4.8) - I may sound unsure cause I've
only recently switched platforms from Linux to FreeBSD just to be different.
> at Apache 2.0.48-dev, you have to do the chmod() on the lock file, like
> mod_ssl does in that branch
OK. Is there an API that returns what the APR_LOCK_DEFAULT mutex will be?
> 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
That would be the ideal solution, but I'm not sure I can wait until
2.0.48. Plus not everyone upgrades when they should, so I need a work
around.
BTW are there any version macros in Apache 2 or the APR like:
APACHE_VERSION_MAJOR
APACHE_VERSION_MINOR
APR_VERSION_MAJOR
APR_VERSION_MINOR
that can be tested at compile time to handle variations?
> 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.
--
Anthony C Howe +33 6 11 89 73 78
http://www.snert.com/ ICQ: 7116561 AIM: Sir Wumpus
" " - Zen thought
Re: apr_global_mutex_child_init & mod_watch
Posted by Anthony Howe <ac...@snert.com>.
> flock is used on FreeBSD by default... flock requires that chmod be
> done on the lock in the child init
As an aside, why is flock() used on FreeBSD? It has SysV like mutexes
and POSIX ones too (at least in 4.8) - I may sound unsure cause I've
only recently switched platforms from Linux to FreeBSD just to be different.
> at Apache 2.0.48-dev, you have to do the chmod() on the lock file, like
> mod_ssl does in that branch
OK. Is there an API that returns what the APR_LOCK_DEFAULT mutex will be?
> 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
That would be the ideal solution, but I'm not sure I can wait until
2.0.48. Plus not everyone upgrades when they should, so I need a work
around.
BTW are there any version macros in Apache 2 or the APR like:
APACHE_VERSION_MAJOR
APACHE_VERSION_MINOR
APR_VERSION_MAJOR
APR_VERSION_MINOR
that can be tested at compile time to handle variations?
> 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.
--
Anthony C Howe +33 6 11 89 73 78
http://www.snert.com/ ICQ: 7116561 AIM: Sir Wumpus
" " - Zen thought