On Sat, Aug 20, 2022 at 09:56:40PM +0200, Willy Tarreau wrote:
> On Sat, Aug 20, 2022 at 09:36:21PM +0200, Ionel GARDAIS wrote:
> > That was it :
> > - remove the EXTRAOPTS from /etc/default/haproxy
> > - stop the running process referencing -x /run/haproxy/admin.sock on the CLI
> > - upgrade
> >
> > All is OK.
> > First processes do not list -x on the CLI and a reload spawn a process with
> > -x sockpair@<inc_id>
>
> Very interesting, thank you Ionel.
>
> There is this fix in 2.6.3 which seems in part related to this:
>
> commit ae1e5a8c72ced4c9527f05bd5b14916d1b9d92c8
> Author: William Lallemand <[email protected]>
> Date: Mon Jul 25 15:51:30 2022 +0200
>
> BUG/MINOR: sockpair: wrong return value for fd_send_uxst()
>
> The fd_send_uxst() function which is used to send a socket over the
> socketpair returns 1 upon error instead of -1, which means the error
> case of the sendmsg() is never catched correctly.
>
> Must be backported as far as 1.9.
>
> (cherry picked from commit f67e8fb92c795808f60b2406ae395ebc0ca180c5)
> Signed-off-by: Christopher Faulet <[email protected]>
>
> However I'm confused by that part in the code because it seems to try
> to send FDs in the function that's supposed to retrieve them, so I'm
> missing something related to the context where this is used. But if
> the caller was not able to properly handle an error, it could possibly
> explain (at least in part) why it failed for you after the upgrade when
> trying to connect if there's an issue with this socket. I'll have to
> check with William on Monday to clarify all this and try to reproduce.
>
> Thanks,
> Willy
It looked like we found the culprit, the patch 3b68b60 ("BUG/MAJOR: log-forward:
Fix log-forward proxies not fully initialized") was not handling the
case where no proxies are in the list.
In master-worker mode, the process is exec() again without any
configuration in order to free the memory, when -S is used to create a
master CLI the list is not empty and everything is good... however
without the -S argument, the list is empty and the master will
indefinitely loop.
So the workaround for this bug is to keep the -S in EXTRAOPTS... which
is the default in haproxy.service. If you rewrote EXTRAOPTS in
/etc/default/haproxy, don't forgot to put it there.
Emeric provided a new patch to fix the problem,
https://github.com/haproxy/haproxy/commit/8032a276ce8007020366d18ebd7400ad5dedc4f4
I'm going to issue a 2.6.4 today with the patch.
--
William Lallemand
