]> git.ipfire.org Git - thirdparty/haproxy.git/commit
BUG/MEDIUM: mworker: fix startup and reload on macOS
authorWilliam Lallemand <wlallemand@haproxy.com>
Thu, 28 Aug 2025 12:18:42 +0000 (14:18 +0200)
committerWilliam Lallemand <wlallemand@haproxy.com>
Thu, 28 Aug 2025 12:51:46 +0000 (14:51 +0200)
commitd7f6819161c933632bd14bf360373ffaae4306fc
tree91f0e39d6be7733052809b6269dff7b59cb97ebb
parent441cd614f92bd3d7d66003e509ae71bcb779b0f5
BUG/MEDIUM: mworker: fix startup and reload on macOS

Since the mworker rework in haproxy 3.1, the worker need to tell the
master that it is ready. This is done using the sockpair protocol by
sending a _send_status message to the master.

It seems that the sockpair protocol is buggy on macOS because of a known
issue around fd transfer documented in sendmsg(2):

https://man.freebsd.org/cgi/man.cgi?sendmsg(2) BUGS section

  Because sendmsg() does not necessarily block until the data has been
  transferred, it is possible to transfer an open file descriptor across
  an AF_UNIX domain socket (see recv(2)), then close() it before it has
  actually been sent, the result being that the receiver gets a closed
  file descriptor. It is left to the application to implement an
  acknowledgment mechanism to prevent this from happening.

Indeed the recv side of the sockpair is closed on the send side just
after the send_fd_uxst(), which does not implement an acknowledgment
mechanism. So the master might never recv the _send_status message.

In order to implement an acknowledgment mechanism, a blocking read() is
done before closing the recv fd on the sending side, so we are sure that
the message was read on the other side.

This was only reproduced on macOS, meaning the master CLI is also
impacted on macOS. But no solution was found on macOS for it.
Implementing an acknowledgment mechanism would complexify too much the
protocol in non-blocking mode.

The problem was reported in ticket #3045, reproduced and analyzed by
@cognet.

Must be backported as far as 3.1.
src/haproxy.c