httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Jagielski <>
Subject Re: New ServerUID directive
Date Fri, 02 Feb 2018 16:45:35 GMT

> On Feb 2, 2018, at 9:42 AM, Stefan Eissing <> wrote:
>> Am 02.02.2018 um 15:25 schrieb Plüm, Rüdiger, Vodafone Group <>:
>>> -----Ursprüngliche Nachricht-----
>>> Von: Jim Jagielski []
>>> Gesendet: Freitag, 2. Februar 2018 15:15
>>> An: httpd <>
>>> Betreff: Re: New ServerUID directive
>>> Why? If it is designed to not change between restarts then
>>> there are much easier ways to be unique, which it kinda
>>> already is, considering the actual structs being used.
>>> Also, this seems like unnecessary admin overhead for the
>>> webmaster... if there is a need for such an ID, httpd should
>>> provide for it automagically and not require users to have
>>> to config one. It seems like config-file fluff to me, IMO.
>> +1. If the current ID used is not meeting our requirements, my first thought would
be if we could improve it
>> to meet them.
> Totally agree that inventing a new Directive is the last resort if we cannot find a better
> If I understand then concrete case here correctly, the admin makes frequent config changes
and *wants* the shared memory id to stay the same, so the shm is re-used and not cleaned up
or re-initialized. And our current implementation generates new identifiers much to frequently
bc the line-number cheat was made to detect config changes?

I think that is correct, which implies, to me, the solution would
be some mod_proxy_balancer Directive like "IgnoreConfigFileChanges"
or something specific like that.

But I am still confused if the above is actually what the issue
is, hence my "resistance" for any modifications at all until
the problem is crystal clear. If we can check, in a one-off
test, that removing that line-number hack solves the "problem"
then that is more easily handled by a specific use-case for

My 2c

View raw message