On 10/07/2019 03:11 AM, Cyril Bonté wrote:
Hi,

Le 06/10/2019 à 09:19, rihad a écrit :
Hi, all. This annoying bug can be experienced in 1.7-2.0 servers (while 1.9 has added another bug of high CPU utilization - unrelated to this). In essence, once an external server that we forward internal requests to stops responding for some time and comes back to life a bit later, more often than not haproxy can no longer reach it.

Without any other details (logs would be helpul), I tend to think there's no bug here, but a configuration issue.

By default, haproxy resolves host names once, on start up. As you are using a host name to delcare the smtp server, which oftenly updates its IPs :

Configuration is very simple

[...]
     server amazon email-smtp.us-west-2.amazonaws.com:587 check inter 30s fall 1440 rise 1


That's it. if email-smtp.us-west-2.amazonaws.com:587 fails intermittently and the downtime lasts more than a few 30 sec checks, it can then no longer be accessed via 127.0.0.2:2588 even if the external servers resumes normal operation, and nothing short of a reload (-sf) fixes the problem.

I guess that when it happens, email-smtp.us-west-2.amazonaws.com has a new pool of IP addresses and haproxy can't connect to the old resolved one. You should have a look to the documentation chapter "Server IP address resolution using DNS" :
https://cbonte.github.io/haproxy-dconv/2.0/configuration.html#5.3


Thanks! But according to the manual, shouldn't haproxy re-resolve AWS server name regardless of its resolver settings?


A few other events can trigger a name resolution at run time:
  - when a server's health check ends up in a connection timeout: this may be
    because the server has a new IP address. So we need to trigger a name
    resolution to know this new IP.

Reply via email to