Ingvar Mattsson
2018-10-12 16:07:47 UTC
When HAProxy tries to set up a socket for a long hostname, it ends up
with an error, as well as wiht a spurious socket left in /var/run.
This seems to be due to a pathname trunctaion when copying the
temporary pathname into the unix socket's "sun_path" (limited to 108
chars, on a couple of randomly investigated linux systems), then using
the tempname to do various operations on the file htat's actually been
created using add.sun_path (the relevant line where the truncation
seems to happen is line 250 in src/proto_uxst.c).
As things stand, there's space for an FQDN no longer than 70
characters, if the PID of haproxy is in the range 10000 <= pid <=
99999, and a few more if the PID happens to be lower.
?Eyeballing the code, it looks as if changing the rename(2) call on line 325 in that file from "rename(tempname, path)" to "rename(addr.sun_path, path)" would be enough to make this go away.
The error log entry looks something like:
[ALERT] 284/123813 (11673) : Starting frontend httpsfront-XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX: cannot switch final and temporary UNIX sockets [/var/run/haproxy-host-XXXXXXXXXXXXX
With the actual error message also being truncated.
The reason for the long-ish hostnames is basically down to the FQDN being <application-name>.<namespace>.k8s.<data centre>.sites.<TLD> in our internal production network and in this specific case, it ended up at 74 octets long.
--------------
G-RESEARCH believes the information provided herein is reliable. While every care has been taken to ensure accuracy, the information is furnished to the recipients with no warranty as to the completeness and accuracy of its contents and on condition that any errors or omissions shall not be made the basis of any claim, demand or cause of action.
The information in this email is intended only for the named recipient. If you are not the intended recipient please notify us immediately and do not copy, distribute or take action based on this e-mail.
All messages sent to and from this e-mail address will be logged by G-RESEARCH and are subject to archival storage, monitoring, review and disclosure.
G-RESEARCH is the trading name of Trenchant Limited, 5th Floor, Whittington House, 19-30 Alfred Place, London WC1E 7EA.
Trenchant Limited is a company registered in England with company number 08127121.
--------------
with an error, as well as wiht a spurious socket left in /var/run.
This seems to be due to a pathname trunctaion when copying the
temporary pathname into the unix socket's "sun_path" (limited to 108
chars, on a couple of randomly investigated linux systems), then using
the tempname to do various operations on the file htat's actually been
created using add.sun_path (the relevant line where the truncation
seems to happen is line 250 in src/proto_uxst.c).
As things stand, there's space for an FQDN no longer than 70
characters, if the PID of haproxy is in the range 10000 <= pid <=
99999, and a few more if the PID happens to be lower.
?Eyeballing the code, it looks as if changing the rename(2) call on line 325 in that file from "rename(tempname, path)" to "rename(addr.sun_path, path)" would be enough to make this go away.
The error log entry looks something like:
[ALERT] 284/123813 (11673) : Starting frontend httpsfront-XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX: cannot switch final and temporary UNIX sockets [/var/run/haproxy-host-XXXXXXXXXXXXX
With the actual error message also being truncated.
The reason for the long-ish hostnames is basically down to the FQDN being <application-name>.<namespace>.k8s.<data centre>.sites.<TLD> in our internal production network and in this specific case, it ended up at 74 octets long.
--------------
G-RESEARCH believes the information provided herein is reliable. While every care has been taken to ensure accuracy, the information is furnished to the recipients with no warranty as to the completeness and accuracy of its contents and on condition that any errors or omissions shall not be made the basis of any claim, demand or cause of action.
The information in this email is intended only for the named recipient. If you are not the intended recipient please notify us immediately and do not copy, distribute or take action based on this e-mail.
All messages sent to and from this e-mail address will be logged by G-RESEARCH and are subject to archival storage, monitoring, review and disclosure.
G-RESEARCH is the trading name of Trenchant Limited, 5th Floor, Whittington House, 19-30 Alfred Place, London WC1E 7EA.
Trenchant Limited is a company registered in England with company number 08127121.
--------------