22.7.7 haproxy fails to start on reboot

[blacksteel1288]

Ok, that now shows the problem, and not resolving a hostname is causing an alert, which then I guess, fails the startup. 

Here's the output of the logfile:

Code: [Select]

[WARNING]  (23218) : parsing [/usr/local/etc/haproxy.conf:114] : a 'http-request' rule placed after a 'use_backend' rule will still be processed before.
[WARNING]  (23218) : parsing [/usr/local/etc/haproxy.conf:116] : a 'http-request' rule placed after a 'use_backend' rule will still be processed before.
[NOTICE]   (23218) : haproxy version is 2.4.19-ec55434
[NOTICE]   (23218) : path to executable is /usr/local/sbin/haproxy
[ALERT]    (23218) : parsing [/usr/local/etc/haproxy.conf:183] : 'server plex' : could not resolve address 'host1.localdomain'.
[ALERT]    (23218) : Failed to initialize server(s) addr.

I tried rebooting a few times and either 1 or 2 different hosts would show up as alerts, so I assume if I correct this one by changing to an IP address, it will just trigger the next host, and so on.

I'm using unbound for DNS, and I'm wondering if there's some issue with waiting for unbound to start and begin resolving addresses at the time of haproxy startup?  Or, DHCP possibly, since these hosts are in DHCPv4 settings and maybe are not getting registered as hosts until too late in the startup process.

Again, odd that this only started in 22.7.7 -- other than changing all hosts to IP addresses, is there any other solution?

[Fright]

oh, unbound...who knows why it might load a second faster or a minute later..config check can take a significant amount of time (I haven't dug for reasons yet. but it's not just the presence of a large blacklist. if I understand correctly, it's being prepared a change in the work of the blacklists and this can greatly speed up work with them).
various documentation states that adding "none"  in DNS Resolve Order option at Services: HAProxy: Settings: Defaults Parameters should help with loading HAProxy in this case (a quick test confirms this. HAProxy loads fine with a known unresolvable backend name and ALERTs switches to WARNINGs at syntax check).

worth a try 

https://www.haproxy.com/documentation/hapee/latest/onepage/#5.2-init-addr

[blacksteel1288]

ok, yes, that worked.

Adding "none" to that config, converted the ALERT into a WARNING and the config check passes on startup, so the haproxy service will startup automatically on reboots.

I did also have to change the log host to it's IP address because that 'none' setting is only relevant for backend servers, not log hosts.  But, that's fine.

Really appreciate all your help!  And, I hope this thread helps someone else with the same issue.

Final thought -- it'd be nice if there was a way to control the ordering of rules in the haproxy configs to eliminate the

Code: [Select]

"[WARNING]  (55248) : parsing [/usr/local/etc/haproxy.conf:112] : a 'http-request' rule placed after a 'use_backend' rule will still be processed before." warnings completely. 

Feature request?

[Fright]

Glad it works and thanks for the feedbacks )

it'd be nice if there was a way to control the ordering of rules in the haproxy configs

Feature request?

think so. the rules order matters

[cookiemonster]

Indeed it matters.
blacksteel, that is not just a noisy warning. The rule is not going to be processed as your config has it but.
Not a defect but the way haproxy works.

[magnust]

Do you have any hostnames instead of IPs in your HA config?


I've had this since forever when I replaced all my IPs with FQDNs so I could swap machines without needing to reconfigure HA, it seems no matter what I do HA fails to look them up and thus fails to start, even with the option to ignore this (DNS resolve order: 'last','libc','none').

Thank you thank you thank you! This has plagued me for ages. Looks solved with your tip!