Re: haproxy fails to properly direct connection to correct back end.
Hi Sander, I simply did apt-get haproxy and configured in a way whatever first google tutorial suggested. It doesn't make sense to read that fine bible manual if you want to try things out. In any case, haproxy does not report any of these warnings and if it fails there is no messages at all. By running haproxy -c -f I get the same *warnings* as you do. And at the end I get this: "Configuration file is valid" > Also using the http-no-delay option is heavily discouraged. That's the only one I really need and that's the point I'm trying to test haproxy. I've read manual only for this cfg option By using '-c -f' at least I know that the option was ignored and that's why I didn't see effect that I expected. From: Sander Klein <roe...@roedie.nl> Sent: July 30, 2017 8:13 AM To: p s Cc: haproxy@formilux.org Subject: Re: haproxy fails to properly direct connection to correct back end. Hi P S, I have to say, the way you type your emails makes one really want to help you. You seem to be positive, constructive and I don't see any whining. And yes, I'm a sarcastic person. So, for your first problem. I don't know what goes wrong, but with me if haproxy fails to start, it actually does give back the reason why it does actually tells me why it doesn't start. The complete error is 'See "systemctl status haproxy.service" and "journalctl -xe" for details.' and 'journalxtl -xe' gives it back nicely. Did you read the output? Now, back to your original issue. I've build a simple setup, added your config, tried to test it and: root@wonko-the-sane:/etc/haproxy# haproxy -c -f /etc/haproxy/haproxy.cfg [WARNING] 210/135916 (26036) : config : 'option forwardfor' ignored for backend 'nodejs' as it requires HTTP mode. [WARNING] 210/135916 (26036) : config : 'option forwardfor' ignored for backend 'nodejs_test' as it requires HTTP mode. [WARNING] 210/135916 (26036) : config : 'option http-no-delay' ignored for backend 'nodejs_test' as it requires HTTP mode. [ALERT] 210/135916 (26036) : http frontend 'all' (/etc/haproxy/haproxy.cfg:16) tries to use incompatible tcp backend 'nodejs' (/etc/haproxy/haproxy.cfg:1) as its default backend (see 'mode'). [ALERT] 210/135916 (26036) : http frontend 'all' (/etc/haproxy/haproxy.cfg:16) tries to use incompatible tcp backend 'nodejs_test' (/etc/haproxy/haproxy.cfg:8) in a 'use_backend' rule (see 'mode'). [ALERT] 210/135916 (26036) : Fatal errors found in configuration. I do not run anything on port 80, nor on 8090 since I do not have to, because *your config is simply broken*. May I suggest you Read The Fine Manual (tm)? https://cbonte.github.io/haproxy-dconv/1.7/configuration.html is a great HAProxy version 1.7.6 - Configuration Manual - GitHub Pages<https://cbonte.github.io/haproxy-dconv/1.7/configuration.html> cbonte.github.io This document covers the configuration language as implemented in the version specified above. It does not provide any hint, example or advice. source. Also using the http-no-delay option is heavily discouraged. Why the project is not hosted on Github, I simply do not know. I'm not the author and I do not get to choose. But to be honest, I couldn't care less where the project is hosted. The support on haproxy has always been great for me and I do not think github would have made that better. Just because it is different and maybe a bit old school for some, doesn't make it really bad. And funny thing is, the other project you are referring to, nginx, isn't on github either Out of office replies to a mailinglist are indeed a bit braindead, but since I have the option to delete emails they do not bother me. Just delete them and *poof* go one with your life. Happy HAProxying! Sander
Re: haproxy fails to properly direct connection to correct back end.
After sending to this list I got spammed by random people telling me that they are on vacation. WTF. It's so much better to report issues on github and not to mess with emails and these random replies. From: p s <mtlr...@hotmail.com> Sent: July 29, 2017 4:05 PM To: haproxy@formilux.org Subject: haproxy fails to properly direct connection to correct back end. I had default version of haproxy from ubuntu, which was 1.5.x, so I decided to update to latest stable first before I report the bug. After I update to latest 1.7.x haproxy stops working with my config. When I was trying to start I was getting: Job for haproxy.service failed because the control process exited with error code. See "systemctl status haproxy.service". systemctl status haproxy.service wouldn't show any info about why haproxy fails. FYI, with nginx it clearly points to what nginx doesn't like, and there is no need to guess. Can this be fixed to properly show errors? So, back to my original issue. Basically, I added only this to the default config: backend nodejs timeout server 1h timeout connect 1s option httpclose option forwardfor server server1 127.0.0.1:80 #check backend nodejs_test timeout server 1h timeout connect 1s option httpclose option forwardfor server server2 127.0.0.1:3000 option http-no-delay frontend all bind *:8090 timeout client 1h option http-no-delay acl is_test path_beg /test use_backend nodejs_test if is_test default_backend nodejs mode http I do not run anything on port 80, now I make a request to example.com/test and haproxy totally fails. 1.5.x would fail with "ERROR 503: Service Unavailable." on first request and would work on second one, 1.7.x doesn't fail that miserably, it just doesn't work at all, and my wget auto-retries 3 times and then it works. I inspected with wireshark what's going on and I see that haproxy when handling my request tries to connect to default backend on port 80 (and I don't run anything on port 80 atm). It's clearly a bug, it shouldn't even touch port 80, and should directly connect to nodejs_test on port 3000. Another point: why don't you host your project on github, it will be way more popular, it would be much easier for anybody to contribute etc. Now, it does feel like haproxy should be avoided, as there is no bugtracker, mailing list that feels broken, etc... feels like it's dying.
haproxy fails to properly direct connection to correct back end.
I had default version of haproxy from ubuntu, which was 1.5.x, so I decided to update to latest stable first before I report the bug. After I update to latest 1.7.x haproxy stops working with my config. When I was trying to start I was getting: Job for haproxy.service failed because the control process exited with error code. See "systemctl status haproxy.service". systemctl status haproxy.service wouldn't show any info about why haproxy fails. FYI, with nginx it clearly points to what nginx doesn't like, and there is no need to guess. Can this be fixed to properly show errors? So, back to my original issue. Basically, I added only this to the default config: backend nodejs timeout server 1h timeout connect 1s option httpclose option forwardfor server server1 127.0.0.1:80 #check backend nodejs_test timeout server 1h timeout connect 1s option httpclose option forwardfor server server2 127.0.0.1:3000 option http-no-delay frontend all bind *:8090 timeout client 1h option http-no-delay acl is_test path_beg /test use_backend nodejs_test if is_test default_backend nodejs mode http I do not run anything on port 80, now I make a request to example.com/test and haproxy totally fails. 1.5.x would fail with "ERROR 503: Service Unavailable." on first request and would work on second one, 1.7.x doesn't fail that miserably, it just doesn't work at all, and my wget auto-retries 3 times and then it works. I inspected with wireshark what's going on and I see that haproxy when handling my request tries to connect to default backend on port 80 (and I don't run anything on port 80 atm). It's clearly a bug, it shouldn't even touch port 80, and should directly connect to nodejs_test on port 3000. Another point: why don't you host your project on github, it will be way more popular, it would be much easier for anybody to contribute etc. Now, it does feel like haproxy should be avoided, as there is no bugtracker, mailing list that feels broken, etc... feels like it's dying.