Hi,
I think we could take this one, however I'm having some comments :
On Mon, Jun 10, 2019 at 04:13:19PM -0500, linuxdaemon wrote:
> --- a/src/checks.c
> +++ b/src/checks.c
> @@ -1891,8 +1891,23 @@ static int prepare_external_check(struct check *check)
> goto err;
> }
>
> - addr_to_str(&s->addr, buf, sizeof(buf));
> - check->argv[3] = strdup(buf);
> + // Make sure to send the unix socket address for the server to the
> external check command
> + if (s->addr.ss_family == AF_INET || s->addr.ss_family == AF_INET6) {
> + addr_to_str(&s->addr, buf, sizeof(buf));
> + check->argv[3] = strdup(buf);
> + }
> + else if (s->addr.ss_family == AF_UNIX) {
> + const struct sockaddr_un *un;
> +
> + un = (struct sockaddr_un *)&s->addr;
> + check->argv[3] = strdup(un->sun_path);
This will still not work for abstract namespace sockets, resulting in an
empty string. Maybe we should think about a way to encode such addresses
and document it so that external checks could use it.
Also, just thinking loud, what above differenciates the argument format
allowing an external check command to detect that this is a unix socket ?
I think we should at least use a prefix that's not allowed in AF_INET
nor AF_INET6 to make it unambigous. Otherwise if your UNIX socket's
address is the text representation of the equivalent IP listening
address (which is not uncommon) such as "192.168.1.35:8080", you will
create confusion for the external check process.
Maybe we should prefix unix sockets paths with "unix:" then we can
prefix abstract sockets with "abns:" ? Or maybe use "unix@" and "abns@"
just like in the haproxy config, that's less work to maintain homogenous
configurations and parsers outside.
Just my two cents,
Willy
