httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Trawick <>
Subject Re: DefaultRuntimeDir
Date Sat, 24 Aug 2013 21:50:47 GMT
On Wed, Aug 21, 2013 at 9:05 AM, Jeff Trawick <> wrote:

> On Wed, Aug 21, 2013 at 8:27 AM, Jim Jagielski <> wrote:
>> The 2.4 STATUS file has:
>>    * opinion on more complete DefaultRuntimeDir use in 2.4.x?
>>      o If a module has a config directive for the run-time file that
>>        treats the configured path as relative to server root, preserve
>>        that behavior but change the location when not configured to
>>        respect DefaultRuntimeDir.  With these changes, users with no
>>        per-runtime-file configuration directives can control
>>        everything with DefaultRuntimeDir.
>>        BUT: Existing users of DefaultRuntimeDir might get a short-term
>> scare
>>        when some unconfigured run-time file starts respecting their
>>        DefaultRuntimeDir directive after an upgrade.
>>        +1: trawick, jim, rjung
>>        rjung: applicable trunk revisions WITHOUT the compatibility tweaks
>>               described above:
>>           scoreboard         r1369477
>>           core/pid file      r1369808
>>           core/mutex         r1370288
>>           mod_socache_XXX    r1370225, r1407385
>>           mod_ldap           r1371684
>>           mod_cache          r1407381
>>           mod_slotmem_plain  r1370763
>>         igalic: We have three votes, what's the status here?
>>        Independently, backport any doc tweaks to 2.4 API migration page.
>> To be honest, I also wonder what the status of this is...
>> I'd like to have the 1st 3 in 2.4, but am unsure what is
>> required, if anything, to make it acceptable. Is it just
>> the "preserve" line?
> I think that we've already backported everything we can without risking a
> change in the meaning of someone's configuration.  DefaultRuntimeDir
> can/should be used for new additions to 2.4 when appropriate, but these
> remaining ones are dangerous without some 2.4-specific mitigation.
> I'll try to look through this in the next day to see if there is some
> mitigation we can do to allow the feature without breaking any current 2.4
> behavior.  I fear that a "safe" implementation would require some explicit
> opt-in for these remaining features, and a config that did the opt-in could
> then move all the runtime files just by changing DefaultRuntimeDir.

Wow, days go by quick if you're learning cmake and shaking the rust off
your Windows-ability...

Here's the best I could come up with:

In 2.4.x branch, DefaultRuntimeDir could take an optional additional
parameter, "full", which means that it applies even to the half-dozen items
that it didn't apply to in 2.4.0-2.4.6.  Those half-dozen modules in 2.4.x
that didn't consult ap_runtime_dir_relative() before would check the global
"full" setting to know whether to start using it like in trunk.  If "full"
isn't specified, those modules would use the same logic they use in

Configure "DefaultRuntimeDir non-default-value full" but don't separately
configure those half-dozen items, and suddenly the scoreboard file and pid
and (usually) some less interesting objects move to the "right" place.

Born in Roswell... married an alien...

View raw message