As described in GH #3528, declaring an UDP log server with "check"
keyword, without specifying check port would result in haproxy
starting a check using TCP oriented API while the underlying address
family was implicit datagram. It would either cause the check to
always fail, or even segfault on some systems where the network API
from the operating system doesn't expect DGRAM family with stream oriented
functions such as "connect()".
To fix the issue, although we do support UDP log endpoints, there is no
UDP checks, and we don't offer ICMP checks, so let's just fallback to
TCP protocol when we detect the address family is DGRAM when starting
a check from a log backend.
The documentation was updated to describe this pitfall.
Many thanks to GH user @ssavant2 for filing a bug report and providing
useful reproducer.
It may be backported to 3.0.
httpchk", "option mysql-check" "option smtpchk", "option pgsql-check",
"option ldap-check", or "option redis-check".
+ For log backends, although UDP endpoints are supported, TCP will be used
+ for checks as implicit protocol, because there is no such thing as rax
+ UDP checks, and ICMP checks are not available.
+
Example:
# simple tcp check
backend foo
srv->check.xprt = xprt_get(XPRT_SSL);
}
+ /* special case for log backends, we enforce stream socket type
+ * if type is DGRAM because although log backends support UDP endpoints
+ * there is no such thing as raw UDP checks, and we don't offer ICMP
+ * checks, so let's stick to TCP (for checks) as per the documentation.
+ */
+ if (srv->proxy->mode == PR_MODE_SYSLOG && srv->check.addr_type.proto_type == PROTO_TYPE_DGRAM) {
+ srv->check.addr_type.proto_type = PROTO_TYPE_STREAM;
+ srv->check.addr_type.xprt_type = PROTO_TYPE_STREAM;
+ }
+
/* Inherit the mux protocol from the server if not already defined for
* the check
*/