We discovered that the sockpair@ protocol is unreliable in macOS, this
is the same problem that we fixed in d7f6819. But it's not possible to
implement a acknowledgment once the socket are in non-blocking mode.
The problem was discovered in issue #3045.
Must be backported in every stable versions.
(cherry picked from commit
8a456399dba70c9880394a7e85f9523feb1505c5)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
(cherry picked from commit
0746af209c3600a908b141f213c8ba7bb807840a)
[cf: ctx adjt]
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
(cherry picked from commit
16ab3761721b11803d6b5df38a487a8bf48a8b49)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
the FD from the unix socket and uses it as if it were the FD
of an accept(). Should be used carefully.
+ Bugs: This protocol is known to be unreliable on macOS because
+ of an issue in the macOS sendmsg(2) implementation. The
+ connection might not be accepted correctly.
+
'unix@<path>' following string is considered as a UNIX socket <path>. this
prefix is useful to declare an UNIX socket path which don't
start by slash '/'.
master. Leaving processes are only accessible with the PID as relative process
number are only usable with the current processes.
+ Bugs: the sockpair@ protocol used to implement communication between the
+ master and the worker is known to not be reliable on macOS because of an
+ issue in the macOS sendmsg(2) implementation. A command might end up without
+ response because of that.
+
Examples:
$ socat /var/run/haproxy-master.sock readline