Hi Pavlos, On Thu, Apr 11, 2019 at 09:47:41AM +0200, Pavlos Parissis wrote: > Hi, > > I am having a rather simple config[1] for testing few changes in haproxyadmin > library and I noticed > that two different map files have the same ID: > > echo 'show map' | socat /run/haproxy/admin1.sock - > # id (file) description > -1 (/etc/haproxy/test_map.map) pattern loaded from file > '/etc/haproxy/test_map.map' used by map at > file '/etc/haproxy/haproxy.cfg-haproxystats' line 75 > -1 (/etc/haproxy/test2_map.map) pattern loaded from file > '/etc/haproxy/test2_map.map' used by map at > file '/etc/haproxy/haproxy.cfg-haproxystats' line 79 (...)
Thanks for your detailed report and the reproducer, I thought I was becoming crazy until I figured it only happens for maps created with use_backend, log-format, or unique-id-format rules. -1 is the uninitialized value. These maps are simply not fully initialized because the initialization was done before they were loaded very late in the boot process, so you cannot correctly update them on the CLI and they will not use the pattern cache. That's fixed with the attached patch that I just merged, all versions since 1.5 have the same bug! Thanks! Willy
>From 0f93672dfea805268d674c97573711fbff7e0e70 Mon Sep 17 00:00:00 2001 From: Willy Tarreau <[email protected]> Date: Thu, 11 Apr 2019 14:47:08 +0200 Subject: BUG/MEDIUM: pattern: assign pattern IDs after checking the config validity Pavlos Parissis reported an interesting case where some map identifiers were not assigned (appearing as -1 in show map). It turns out that it only happens for log-format expressions parsed in check_config_validity() that involve maps (log-format, use_backend, unique-id-header), as in the sample configuration below : frontend foo bind :8001 unique-id-format %[src,map(addr.lst)] log-format %[src,map(addr.lst)] use_backend %[src,map(addr.lst)] The reason stems from the initial introduction of unique IDs in 1.5 via commit af5a29d5f ("MINOR: pattern: Each pattern is identified by unique id.") : the unique_id assignment was done before calling check_config_validity() so all maps loaded after this call are not properly configured. From what the function does, it seems they will not be able to use a cache, will not have a unique_id assigned and will not be updatable from the CLI. This fix must be backported to all supported versions. --- src/haproxy.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/haproxy.c b/src/haproxy.c index ef52e31bc..517c62fe4 100644 --- a/src/haproxy.c +++ b/src/haproxy.c @@ -1663,14 +1663,14 @@ static void init(int argc, char **argv) } } - pattern_finalize_config(); - err_code |= check_config_validity(); if (err_code & (ERR_ABORT|ERR_FATAL)) { ha_alert("Fatal errors found in configuration.\n"); exit(1); } + pattern_finalize_config(); + /* recompute the amount of per-process memory depending on nbproc and * the shared SSL cache size (allowed to exist in all processes). */ -- 2.20.1
