maxconn 4000
user haproxy
group haproxy
daemon
stats socket /var/lib/haproxy/stats
defaults
timeout connect 5m
timeout client 60m
timeout server 60m
log global
mode tcp
option tcplog
maxconn 3000
source 10...4
listen x
bind *:445
server hostname:445 hostname:445 check
My question is, I had issues with DNS names that were not solvable anymore - then HAProxy is not willing to start. Despite the fact that there are other entries that are working - can I configure that behaviour? Shouldn’t HAProxy just skip that entry and start anyway?
There is a difference between “does not start” and “stop”. In this case, haproxy will reject the configuration and rightly so, otherwise you would have a partially or completely dysfunctional instance.
You can disable this behavior by specifying none as the last resolution method, however you should also setup haproxy resolvers so that this situation is actually recoverable.
I also have this issue. It is due to a container failing to start because a NAS hasn’t booted. I would prefer to be able to access the remaining services I have until that can be resolved.
Is there any issues with doing the configuration you have shown?
Many thanks, that is indeed the solution.
I would expect from a solution which is called “High-Availability”-proxy to have this behavior set by default. imho
That’s an erroneous assumption. Haproxy never stops the service. This is about rejecting a invalid configuration that references hostnames that don’t resolve AT STARTUP during configuration parsing.