William Lallemand

This is now available in master and will be in 2.7, I'm closing the ticket.

Looks like a post-parsing error which was not hidden for the httpclient... The connect() is actually done on the UDP socket just to ensure that the route is available to...

I agree with you on that, in my opinion it shouldn't block at startup. Unfortunately it wasn't designed like that, and people are setting `After=network-online.target` in their unit file to...

Indeed that won't fix all the issues, the network-online.target doesn't cover every cases :( Honestly I think it even prevent people to write their configuration correctly and to report that...

https://github.com/haproxy/haproxy/commit/b10b1196b864b50bb1c781bd0064a1176467046f https://github.com/haproxy/haproxy/commit/866b88bc95d19c06633fc57a577e5aaf57baf23c https://github.com/haproxy/haproxy/commit/866b88bc95d19c06633fc57a577e5aaf57baf23c These patches are also required, it must completely fix the issue..

You can check with the current 2.6 branch, it includes the patches, they will be in the next minor release (2.6.5)

I couldn't reproduce this issue. Do you reproduce this problem for each reload? Since 2.6, the seamless reload use the mworker socketpairs to get the old sockets, so "expose-fd listeners"...

I caught an old problem in the sockpair protocol, it looks like the wrong error code was returned when the connexion failed, I fixed it in commit f67e8fb. At least...

I got what the problem is, when having remaining processes, an old process could be chosen to get the sockets, but the there is no socket anymore in this one,...

@geofffranks HAProxy 2.5 is not able to use the internal socketpairs to retrieve the bind of the listeners, so that's not the same issue. Please update to the latest HAProxy...