On Fri, Feb 2, 2018 at 5:52 PM, Jim Jagielski <j...@jagunet.com> wrote:
> But we already have a unique ID in the form of
> the actual server struct itself, which contains
> all the data required to make a vhost "unique"

Sure, my patch or any other way to compute an automatic UID for a
vhost don't need anything else than the server_rec.
More exactly the proposed patch needs all the servers because it
doesn't take the line number into account, and nothing prevents
multiple exact same vhosts to be configured (totally useless, so an
implementation detail and not the point here).

> The only "issue" is what makes a host "unique"... IMO,
> in an environ where the definition line of the vhost changes
> between restarts is a "new" vhost and that was the assumption
> that the implementation was based on.

I don't deny it can be a valid assumption for some cases, but I
observe that it breaks others like "automatic vhost UID should remain
the same when some totally unrelated line is added before it".

> *But that assumption can more easily be changed by providing
> a work-around for that specific use case*

I'm not proposing this directive to address the mod_proxy_lb case, and
just gave it as an example for an in-tree case where it would be
useful (at least a new automatic UID is needed I think).
That case just reminded me that I had a patch somewhere for the
ServerUID, which is actually part of a larger one for a per-vhost
scoreboard/logio stuff which I already talked about some times ago
(with no apparent feedback/interest).
This larger patch really needs a vhost UID for stats to be relevent
days/month/years later, regardless of minor configuration changes,
even for things like vhost IP or port (which does not matter too much
in a local network, not to talk about line numbers...) or
ServerName/Alias (nothing mandates them for a vhost to work, e.g. IPs
only and ProxyPreserveHost).
Anyway, if you already have an UID in an User Interface to identify a
vhost, put it in ServerUID for httpd to use it where needed internally
and/or to "print" that UID anywhere you configured it to (e.g.
%{SERVER_UID} in access_log, headers, expr, ...).
At the end of the day, the webmaster really talks about the ServerName
or this "UID" to refer to a vhost (they can be and even usually are
the same modulo ports 80/443), but never about the IP or line number
it once had.

Sooo :) instead of proposing the change on how we can uniquely
identify a vhost for mod_proxy_lb only (in an automatic way or not), I
thought ServerUID could start its upstream life.

> instead of creating a
> whole new Directive for a "generic" server UID which:
>   1. Implies that the webmaster must know when and how that UID
>      is used internally

How is it different than now, or than anything we could do
automatically/unconditionaly based on the server_rec?
This argument sounds to me like we really need the ServerUID, if the
webmaster really wants httpd to use an ID which does not depend on
whatever future change to the configuration, (s)he has to provide that
ID or know the internals.
The only requirement on the httpd side is that an given ServerUID is
unique (that should be documented, though the directive name not
really ambiguous). It shouldn't be too hard for the user, UUID or

>   2. Add more Directive cruft to an already bloated collection
>      of directives.

That's a very valid concern! But I think my proposal is quite
orthogonal to the mod_proxy_lb issue, and it doesn't avoid us to find
one (or Stefan's multiple) good way to uniquely identify a vhost when
no ServerUID is specified.

> Instead, as I said, we should have a specific balancer directive
> or option, complementing the Persist-related ones, that either
> have the config line number included or not in the hash, ala
> "IgnoreConfigFileChange" (or whatever)

That's a new directive too, very specialized (though it's your point).
Wouldn't it end up being declined to other modules one day or the other?
But mainly, rather than ignoring config changes, I think mod_proxy_lb
should ignore non-changes.
And it already knows how to do that provided the vhost's balancer id
does not change unnecessarily...

It really matters for (graceful) restarts only, because otherwise we
don't need to reuse names or slotmems (besides Mark's unusual issue,
see [1] below).
Why would one restart httpd if not to apply some configuration change?
Whether this change relates to balancers or not is something the
webmaster shouldn't care about (and figure out if
IgnoreConfigFileChange should be on/off, depending on the kind of
change, before the next restart).


[1] AIUI, the issue Mark encounters with balancers is that the main
process crashes because of third party modules, leaking IPC-SysV SHMs
to the system (many balancers thus many leaks).
Since his configuration file changes often, the SHMs are not cleaned
up on the next startup either (their names changed with line numbers).
So I proposed, as a *workaround* before the root cause if fixed in
third party modules and to unblock his production, a temporary patch
to remove line numbers from the computation of the SHMs names.
But the ServerUID proposal is not meant to address Mark's unusual
case, I mean the unusual case where the parent process crashes,
because (frequent) restarts are not that unusual and should be fixed

Reply via email to