httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Trawick <>
Subject Re: Tagged 2.0
Date Wed, 17 Sep 2003 12:14:41 GMT
Sander Striker wrote:

> I've re tagged the 2.0 tree with STRIKER_2_0_48_PRE2.  I've
> put some tarballs containing that tag up at:

There are some other fixes merged back since then, and it looks like 
another set of fixes that are close to being approved.

Here is one issue I'd strongly suggest resolving for 2.0.48:

Greg indicated in the last couple of days that had almost 
12000 error messages (at that point) related to mutex errors with 
mod_rewrite.  That affects flock users (e.g., FreeBSD) starting the 
server as root.  I would suggest picking up this change to resolve that:

-    * Unix: Handle permissions settings for flock-based mutexes in
   -      unixd_set_global|proc_mutex_perms().  Allow the functions to
   -      be called for any type of mutex.  PR 20312
   -        modules/mappers/mod_rewrite.c 1.153
   -        modules/ssl/mod_ssl.h 1.136
   -        modules/ssl/ssl_engine_config.c 1.81
   -        modules/ssl/ssl_engine_mutex.c 1.26
   -        os/unix/unixd.c 1.58
   -        os/unix/unixd.h 1.38
   -        +1: trawick, jerenkrantz, gregames
   -         0: jim (it seems to me that the locking mech itself
   -                 should have the required flags to determine whether
   -                 uid/gid and chown is required, rather than placing
   -                 that knowledge in unixd.c (kind of what is done for
   -                 the SSL stuff already with ChownMutexFile). Thus
   -                 unixd would simply check those out and do what is
   -                 required rather than having internal APR knowledge
   -                 it shouldn't).

I think the critical issue with this one is that, while the lessor-used 
lock in mod_rewrite had this problem all along, another fix in 2.0.47 
started doing the child-init on the other mod_rewrite lock and it too 
picked up the root/flock issue.

Beyond this one, I'm afraid that I'm not very familiar with the 
real-world implications of not picking up the other available fixes.

I'd like to think that within a couple of days we could get 7 or 8 more 
fixes merged back, at which point we'd be ready for another release 
anyway.  But it wouldn't be prudent to count on that happening ;)

View raw message