Re: [PR] Fix backend typo
Hi Rick, thanks for your first patch. I've adjusted the commit message and merged it. Please next time have a look at CONTRIBUTING to see how to properly format your commit messages and submit your patches, this makes the process smoother and does help quite a bit. Thanks, Willy
Re: Query: Respond with same tos/dscp value as incoming request tos/dscp value
Hi Nikhil, On Tue, Oct 08, 2019 at 04:09:49PM +0530, Nikhil Agrawal wrote: > Hi, > > I have a use case where i need http response from haproxy with same > tos/dscp value as incoming packet. > > I found the set-tos in haproxy but no option to dynamically set the same as > incoming request. > > Is there any way to do the same in haproxy. No indeed we do not have this in the other way around. I suggest you try to experiment a bit with getsockopt(IP_TOS) to see what is reported. Indeed, I don't know what the kernel will report, if it is the last known TOS for a connection, the first one seen on the SYN packet or anything else. If you figure we can get any useful information then I think it makes sense to slightly modify the set-tos action so that in addition to taking a numeric value it also accepts an expression. In this case we could have fc_tos() and bc_tos() to get the TOS field from either the front or the back connection, and use it in set-tos to adjust the TOS in responses to the client. Given that it's not something critical I'm fine with getting this merged at the last minute before the 2.1 release if needed. Willy
Re: Issue with HTX
Hi Ionel, On Tue, Oct 08, 2019 at 03:33:16PM +0200, GARDAIS Ionel wrote: > Hi, > > I'm facing a data corruption that seems related to HTX. > Simply adding 'no option http-use-htx' solve the issue. > > What kind of traces do you need to help diagnose the issue and how to collect > it ? Ideally a network capture before and after haproxy will help. Are you sure you're running on an up-to-date version ? Christopher addressed one such issue recently in H2. If you're able to reproduce this at will, it may be useful to run on latest 2.1-dev, where we can help you enable H1+H2 debug traces. Thanks, Willy
Issue with HTX
Hi, I'm facing a data corruption that seems related to HTX. Simply adding 'no option http-use-htx' solve the issue. What kind of traces do you need to help diagnose the issue and how to collect it ? Thanks, Ionel -- 232 avenue Napoleon BONAPARTE 92500 RUEIL MALMAISON Capital EUR 219 300,00 - RCS Nanterre B 408 832 301 - TVA FR 09 408 832 301
Query: Respond with same tos/dscp value as incoming request tos/dscp value
Hi, I have a use case where i need http response from haproxy with same tos/dscp value as incoming packet. I found the set-tos in haproxy but no option to dynamically set the same as incoming request. Is there any way to do the same in haproxy. Thanks in advance. Regards, Nikhil Agrawal -- *-* *This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error, please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee, you should not disseminate, distribute or copy this email. Please notify the sender immediately by email if you have received this email by mistake and delete this email from your system. If you are not the intended recipient, you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited.* *Any views or opinions presented in this email are solely those of the author and do not necessarily represent those of the organization. Any information on shares, debentures or similar instruments, recommended product pricing, valuations and the like are for information purposes only. It is not meant to be an instruction or recommendation, as the case may be, to buy or to sell securities, products, services nor an offer to buy or sell securities, products or services unless specifically stated to be so on behalf of the Flipkart group. Employees of the Flipkart group of companies are expressly required not to make defamatory statements and not to infringe or authorise any infringement of copyright or any other legal right by email communications. Any such communication is contrary to organizational policy and outside the scope of the employment of the individual concerned. The organization will not accept any liability in respect of such communication, and the employee responsible will be personally liable for any damages or other liability arising.* *Our organization accepts no liability for the content of this email, or for the consequences of any actions taken on the basis of the information *provided,* unless that information is subsequently confirmed in writing. If you are not the intended recipient, you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited.* _-_
[PR] Fix backend typo
Dear list! Author: Rick Rackow Number of patches: 1 This is an automated relay of the Github pull request: Fix backend typo Patch title(s): Fix backend typ Link: https://github.com/haproxy/haproxy/pull/316 Edit locally: wget https://github.com/haproxy/haproxy/pull/316.patch && vi 316.patch Apply locally: curl https://github.com/haproxy/haproxy/pull/316.patch | git am - Description: Instructions: This github pull request will be closed automatically; patch should be reviewed on the haproxy mailing list (haproxy@formilux.org). Everyone is invited to comment, even the patch's author. Please keep the author and list CCed in replies. Please note that in absence of any response this pull request will be lost.
"official" rpm repo ?
hi, I played a bit with Fedora COPR (it is nice) https://copr.fedorainfracloud.org/coprs/chipitsine/haproxy/build/1041926/ few questions 1) do we insist on Lua support ? (it is hard to get Lua-5.3 for EPEL7) 2) any best practice on building new packages ? anyway, I do not insist in running my very own repo (I started to work with packages because I did not find any good repo with recent haproxy builds), I can give those packages back to haproxy itself (if there's an interest) thanks, Ilya Shipitsin
Re: healthchecks (to uwsgi) possible regression 1.9.8 -> 1.9.9
Hi Jarno, On Fri, Oct 04, 2019 at 07:28:15PM +0300, Jarno Huuskonen wrote: > I sent pcap/strace offlist. Thanks, that was very useful. > (strace -f -o -ttt, tcpdump -n -p -s 16384 -w ... host 127.0.0.1 and > port 8080). > > I think in packet capture the second health checks causes > "client_addr: 127.0.0.1 client_port: 2779] hr_read(): Connection reset by > peer [plugins/http/http.c line 917]" > (I think uswgi logs client_port incorrectly, ntohs(2779) gives 56074 > (and port 56074 is in packet capture)). It's as usual, when you start to troubleshoot a bug you find a myriad of other ones around :-) > (haproxy version: HA-Proxy version 2.1-dev2 2019/10/01). > > I tried to reproduce with very minimal flask/uwsgi hello world app > and there hr_read happens very rarely. > With alerta(.io) app this happens more regularly (AFAIK not with every check). > So maybe this is weird timing issue or bug in uwsgi. So it is indeed a timing issue. The check running on port 56062 shows the following sequence: 17:10:57.877876 IP localhost.56062 > localhost.8080: Flags [S] 17:10:57.877898 IP localhost.8080 > localhost.56062: Flags [S.] 17:10:57.877909 IP localhost.56062 > localhost.8080: Flags [.] 17:10:57.878065 IP localhost.56062 > localhost.8080: Flags [P.] 17:10:57.878078 IP localhost.8080 > localhost.56062: Flags [.] 17:10:57.879933 IP localhost.8080 > localhost.56062: Flags [P.] 17:10:57.879939 IP localhost.56062 > localhost.8080: Flags [.] 17:10:57.880008 IP localhost.8080 > localhost.56062: Flags [F.] 17:10:57.880333 IP localhost.56062 > localhost.8080: Flags [F.] 17:10:57.880341 IP localhost.8080 > localhost.56062: Flags [.] Note the FIN sent 75 microseconds after the response. This resulted in recvfrom() returning zero and the connection to be cleanly closed. Now regarding port 56074 that is causing excess logs : 17:11:04.132867 IP localhost.56074 > localhost.8080: Flags [S] 17:11:04.132890 IP localhost.8080 > localhost.56074: Flags [S.] 17:11:04.132904 IP localhost.56074 > localhost.8080: Flags [.] 17:11:04.133083 IP localhost.56074 > localhost.8080: Flags [P.] 17:11:04.133098 IP localhost.8080 > localhost.56074: Flags [.] 17:11:04.135101 IP localhost.8080 > localhost.56074: Flags [P.] 17:11:04.135107 IP localhost.56074 > localhost.8080: Flags [.] 17:11:04.135316 IP localhost.56074 > localhost.8080: Flags [R.] As you can see, even 215 microseconds after the response there is still no FIN. I've checked and in both cases the headers are the same. There is indeed a "connection: close" header emitted by haproxy, none is advertised in the response, but clearly it's a matter of delay. And this causes recvfrom() to return EAGAIN, so haproxy is forced to hard- close the connection (as if it were doing option http-server-close). Please also note that returned data are properly ACKed so there is not much more we can do there. Before the patch that you bisected, you didn't face this because of a bug that was preventing the hard close from working, and instead you were accumulating TIME_WAIT sockets on the client side. So I'm afraid to say that for now the best I can say is that you'll still have to live with these occasional logs :-/ I'd really like to see a massive rework being done on the checks. Your report made me realize that there is one feature we're currently missing, which is the ability to wait for a close once we've got a response. At the moment we cannot add this because checks work in 2 steps : 1) connect and send the "request" 2) receive the "reponse" and close. There's no real state machine there, it's roughly "if request was not sent, send it, otherwise try to receive a response; if response is received, then process it and close otherwise wait for response". So we cannot remain in a "waiting for closing" state after we receive a response. I'm wondering if that couldn't be achieved using tcp-checks however. I quickly tried but couldn't find a reliable way of doing this but I'm thing that we could possibly extend the tcp-check rules to have "tcp-check expect close" that would wait for a read0. Regards, Willy
