Closed xpiotr87x closed 2 years ago
Intersting, this is the first time I'm seeing it on something that looks like valid traffic. We triggered it for the first time 3 weeks ago while stressing the master-CLI. I guess that sometimes the traffic from/to SVN is bursty and causes many short wakeups. There were a few recent fixes at the channel level that might possibly have increased the likelihood to trigger it.
The attached patch that is planned for backporting should fix it by relaxing the condition to only care about wakeups without any transfer. Could you please try to rebuild with it to confirm ? Note that the chunk that changes the comment in include/haproxy/stream-t.h will fail to apply on 2.0 but you can safely ignore it, it's just a comment. Do not hesitate to tell us if you're not at ease with applying patches, we'll guide you.
Thanks for your report!
The attached patch
@wtarreau There's no attachment on your comment.
Also I guess that rebuilding for the reporter is non-trivial, because they use Vincent's Ubuntu PPA.
Sorry, as usual... I noticed the reporter was using Vincent's PPA, but some know how to do that, others don't, that's why I still preferred to ask ;-)
0001-BUG-MINOR-stream-make-the-call_rate-only-count-the-n.patch.txt
Thanks for the quick reply. I prepared two servers using VIP to be able to switch between them (working Centos with 2.0.25 / problematic Ubuntu with 2.0.27) Unfortunately I don't know how to do the rebuild. In source from Vincent's PPA there is an additional directory "debian" with additional files/patches and I don't know how to include them in build. I need some tips how to properly install your patch
OK if you don't know how to rebuild, I fear that we guide you through a process where you will feel uncomfortable, and it may require multiple round trips to help you install the required dependencies, plus I'm not fan of installing dev tools on servers, so this will complicate the process a bit further as I'm assuming you don't even have a dedicated build machine.
If the issue happens at a bearable frequency, the best I can propose you is to wait for next release, ideally next week, maybe the one after. The patch was marked for "backport only if anyone reports this issue". The condition is already met, and as we planned to emit a new release soon, it will come with it and you'll get other fixes plus this one from the official repo.
Does this suit your expectations ?
Yes thank you, I will wait for the next release, sticking to a older stable, working version. If the newer version does not help, I will prepare a dedicated test environment to allow for better analysis and let you know
New version solved the problem. Thanks for support
Perfect, thank you for the feedback!
Detailed Description of the Problem
After migration from Centos 7 + HA-Proxy version 2.0.25-6986403 OpenSSL 1.1.1l to Ubuntu 20.04 + HA-Proxy version 2.0.27-1ppa1~focal OpenSSL 1.1.1f During more traffic to our svn server proxy die with code 134
Expected Behavior
I expect the process run without reboots
Steps to Reproduce the Behavior
large number of requests to svn server via proxy
Do you have any idea what may have caused this?
No response
Do you have an idea how to solve the issue?
No response
What is your configuration?
Output of
haproxy -vv
Last Outputs and Backtraces
Additional Information
No response