Hi all,
I add Vincent Bernat to the discussion.
Le 14/01/2016 00:10, Cyril Bonté a écrit :
Hi,
Le 13/01/2016 23:50, Willy Tarreau a écrit :
Hi Mike,
On Wed, Jan 13, 2016 at 10:39:00AM -0600, Mike Pastore wrote:
Hi Willy,
Thank you for the response and for all your excellent work on HAproxy. I
just started working with it this week but I've quickly come to
appreciate
and enjoy working with it.
That's because you're still doing simple and efficient configs, wait for
some people to suggest anti-ddos setups and you'll start scratching your
head :-)
I tried moving the -L before the -f and there was no change in the
behavior.
OK thanks testing. I'll see if I can reproduce it.
I also had a look yesterday but can't see any reason it could happen. I
tried the same config with the same command line and also reviewed the
code.
At init, the content of localpeer is set to the current hostname, but is
replaced by any value provided with "-L" during the command line parsing.
The configuration files are only parsed after that, so the "localpeer"
content should be cleanly set when during configuration validation step.
Mike, how are you testing ? Could it be that you are using an init
script instead of the command line you provided, which may forget to
provide the -L argument ?
I could make some more tests in a docker instance of ubuntu 14.04 and
haproxy 1.6.3 (from ppa:vbernat/haproxy-1.6).
Good news, there is nothing wrong in haproxy, the "-L" option is
correctly applied to he loaded configuration.
But the init script first checks the configuration in
check_haproxy_config(), which doesn't take into account EXTRAOPTS. This
is this part which produces the warning :
check_haproxy_config()
{
$HAPROXY -c -f "$CONFIG" >/dev/null
if [ $? -eq 1 ]; then
log_end_msg 1
exit 1
fi
}
Maybe the init script should be updated to add $EXTRAOPTS everywhere.
--
Cyril Bonté
