Thanks Aurelien, I feel less lonely on this.
I might add that sometime as well the server check results switches to 4
= CHK_RES_CONDPASS which seems to indicate a bug in the handling of the
maxconn parameter.
I will run experiments without the maxconn to confirm (or not) the culprit.
On 08/02/2023 09:38, Aurelien DARRAGON wrote:
Hi,
I don't know if it could help, but based on Thomas instructions/example,
I'm able to reproduce:
As weird as it may seem, the 'maxconn' parameter used with dynamic
server seems to trigger the issue.
Below is a minimal reproducer:
global
stats socket /tmp/ha.sock mode 660 level admin expose-fd listeners
defaults
timeout client 5s
timeout server 5s
timeout connect 5s
frontend test
mode http
bind *:8081
use_backend farm
listen dummyok
bind localhost:18999
mode http
http-request return status 200 hdr test "ok"
backend farm
mode http
(it doesn't matter if the backend starts with empty server list)
Step 1 (optional), test the reference behavior without maxconn:
Start haproxy and perform the following :
echo "add server farm/t1 127.0.0.1:18999" | nc -U /tmp/ha.sock
echo "enable server farm/t1" | nc -U /tmp/ha.sock
curl localhost:8081 -> OK
Step 2, compare behavior when maxconn is in play:
Start haproxy and perform the following :
echo "add server farm/t1 127.0.0.1:18999 maxconn 100" | nc -U /tmp/ha.sock
echo "enable server farm/t1" | nc -U /tmp/ha.sock
curl localhost:8081 -> 503 after 5s connect timeout
Regards,
Aurelien
