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 www.apache.org 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 ;)



Reply via email to