HAProxy 1.8 Config reload issues

Help!
21

We downed a set of backend nodes so our nbsrv() returned 0 without restarting haproxy and we were routed to our maintenance page so it appears to be functioning as we expect it to.

If nbsrv=0 & stopping=false then maint page
If nbsrv=1+ & stopping=false then normal backend routing
If nbsrv=1+ & stopping=true then normal backend routing

All these look to be working correctly. We do see a dip in our connection rate and a spike in our connection time during reloads, but we don’t have any incorrectly routed traffic. This is using the state file with our reloads.

Is that the best method or would the expose-fd listenert be for process transitions?

22

The seamless reload feature with expose-fd fixes a small race condition during reload and makes sure, absolutely no SYN packets are rejected by the kernel.

It does not pass sessions from the old process to the new. You can enable it, but if that race condition didn’t come up in your tests, you won’t notice a difference.

23

I think this patch is good to solve the nbsrv problem, but i don’t found it in the following version. Did it has other problem?

25

It doesn’t solve the problem at all, for example:

acl Ale0 nbsrv(A) le 0
acl STOPPING stopping
use_backend B if Ale0 ! STOPPING
default_backend A

When backend A and B is usable, it feels good. However, when B is usable and A is always down, the request should be routed to B. If haproxy reloads in this time, the request cannot be routed to B, and A is down, the problem still exists. I hope the patch in function be_usable_srv() can be applyed in following version, for solving this problem.

26

The behavior will not change, the patch in this thread will not be applied because the change fixes a legitimate problem, as explained earlier.

You have all the flexibility with use_backend rules, to do exactly as you please, you just need to configure it accordingly.

1 Like