Re: [PATCH][MINOR] Implement resovle-opts with 2 new options
On Wed, Aug 08, 2018 at 11:42:48PM +0200, Baptiste wrote: > Until HAProxy 1.7, the DNS resolver was able to allocate the same IP > address to all (or a portion of) servers sharing the same hostname and > being in the same backend. > This behavior annoyed the people who wants to scale based on DNS response, > hence we introduced prevention of duplication of IP addresses for servers > sharing the same hostname and being in the same backend. So we fixed it in > 1.8 with no possibility no "disable" this behavior. > There are still some use cases where people may want to use the same IP > address for multiple servers (they are running several instances of the > same application on a server but on different ports, they use the same dev > server several times in the backend, etc...). > > So this patch doesn't change default behavior introduced in 1.8 while > allowing to change it when required. Many thanks, now backported with a summary of this explanation. Willy
Re: Server State File not loading.
That's because you may be in master-worker mode. Please remove the '-Ws' and the master-worker keyword from your config file. Also, could you please send the content of the state file? (you can send it to me only if there is sensitive data inside) On Thu, Aug 9, 2018 at 5:15 AM, Dustin Schuemann wrote: > Running in debug mode doesn't show much. > > /usr/sbin/haproxy -Ws -f /etc/haproxy/haproxy.cfg -p /run/haproxy.pid -V > [WARNING] 220/031353 (21386) : stats socket will not work as expected in > multi-process mode (nbproc > 1), you should force process binding globally > using 'stats bind-process' or per socket using the 'process' attribute. > [WARNING] 220/031353 (21386) : Setting tune.ssl.default-dh-param to 1024 > by default, if your workload permits it you should set it to at least 2048. > Please set a value >= 1024 to make this warning disappear. > [WARNING] 220/031353 (21386) : Proxy 'stats': in multi-process mode, stats > will be limited to process assigned to the current request. > Note: setting global.maxconn to 2000. > Available polling systems : > epoll : pref=300, test result OK >poll : pref=200, test result OK > select : pref=150, test result FAILED > Total: 3 (2 usable), will use epoll. > > Available filters : > [SPOE] spoe > [COMP] compression > [TRACE] trace > Using epoll() as the polling mechanism. > > > > On Wed, Aug 8, 2018 at 9:24 PM Baptiste wrote: > >> So I don't expect this is a bug >> >> On Thu, Aug 9, 2018 at 4:16 AM, Dustin Schuemann >> wrote: >> >>> I don’t believe so. >>> >>> I just have IP addresses in my backend configuration >>> >>> >>> >> So I don't expect this is a bug. >> Might be a misconfiguration somwhere. >> What does HAProxy says when you run it in debug mode ? >> >
Re: Server State File not loading.
Running in debug mode doesn't show much. /usr/sbin/haproxy -Ws -f /etc/haproxy/haproxy.cfg -p /run/haproxy.pid -V [WARNING] 220/031353 (21386) : stats socket will not work as expected in multi-process mode (nbproc > 1), you should force process binding globally using 'stats bind-process' or per socket using the 'process' attribute. [WARNING] 220/031353 (21386) : Setting tune.ssl.default-dh-param to 1024 by default, if your workload permits it you should set it to at least 2048. Please set a value >= 1024 to make this warning disappear. [WARNING] 220/031353 (21386) : Proxy 'stats': in multi-process mode, stats will be limited to process assigned to the current request. Note: setting global.maxconn to 2000. Available polling systems : epoll : pref=300, test result OK poll : pref=200, test result OK select : pref=150, test result FAILED Total: 3 (2 usable), will use epoll. Available filters : [SPOE] spoe [COMP] compression [TRACE] trace Using epoll() as the polling mechanism. On Wed, Aug 8, 2018 at 9:24 PM Baptiste wrote: > So I don't expect this is a bug > > On Thu, Aug 9, 2018 at 4:16 AM, Dustin Schuemann > wrote: > >> I don’t believe so. >> >> I just have IP addresses in my backend configuration >> >> >> > So I don't expect this is a bug. > Might be a misconfiguration somwhere. > What does HAProxy says when you run it in debug mode ? >
Re: Server State File not loading.
So I don't expect this is a bug On Thu, Aug 9, 2018 at 4:16 AM, Dustin Schuemann wrote: > I don’t believe so. > > I just have IP addresses in my backend configuration > > > So I don't expect this is a bug. Might be a misconfiguration somwhere. What does HAProxy says when you run it in debug mode ?
Re: Server State File not loading.
I don’t believe so. I just have IP addresses in my backend configuration Sent from my iPhone > On Aug 8, 2018, at 8:59 PM, Baptiste wrote: > > > >> On Thu, Aug 9, 2018 at 3:24 AM, Dustin Schuemann >> wrote: >> I'm using HAproxy 1.8.8 and the server state file won't load. >> >> My configuration is as follows >> >> [global] >> server-state-file /etc/haproxy/haproxy.state >> [defaults] >> load-server-state-from-file global >> >> I've verified that the servers I changed via the socket are in the state >> file. > > > Hi Dustin, > > Are you using DNS resolution based on SRV records for those servers? > > Baptiste
Ideas For Getting Online Sales For haproxy.com
Dear haproxy.com Team, Hope you are doing good. I checked your website haproxy.com and wanted to shoot you a quick note. If you want we can make few changes to make your site convert more visitors into leads and to place it higher in the organic search for some selected terms. If you are not on Google's first page, your website is a waste. If you want to know the major issues of your website, I am sending few points below. - Due to poor and unauthorized link sites. - Relevant keyword phrases are not visible on first page listing. - Your website is not search engine friendly. - Website content quality is not high standard. - Website is having on-page and on-site issues. *Area of Improvement:* - Get quality content and theme based back links. - We will give you 1st page ranking on Google, Yahoo and Bing. - Improve your organic traffic and sales. - Secure your website from Google penguin updates 4.0 - Target your local market to increase business. Note*: We give guarantee to improve your keyword ranking from the first month itself, if we fail to achieve then we will refund your money. Our main objective is to increase your website's online visibility which results in improvement in traffic, link popularity, goal conversion and ROI. For more details please reply. We have your *WEBSITE ANALYSIS REPORT *ready with us. *Thanks & Regards,* Guy Burton Digital Marketing Expert -- *Disclaimer: *We are not spammer. We found your email through manual effort. This is a onetime email and you may ask us to *"remove"* so we will delete your email from our list. [image: beacon]
Re: Server State File not loading.
On Thu, Aug 9, 2018 at 3:24 AM, Dustin Schuemann wrote: > I'm using HAproxy 1.8.8 and the server state file won't load. > > My configuration is as follows > > [global] > server-state-file /etc/haproxy/haproxy.state > [defaults] > load-server-state-from-file global > > I've verified that the servers I changed via the socket are in the state > file. > Hi Dustin, Are you using DNS resolution based on SRV records for those servers? Baptiste
Re: [PATCH][MINOR] Implement resovle-opts with 2 new options
On Wed, Aug 8, 2018 at 11:09 PM, Willy Tarreau wrote: > Hi Baptiste, > > On Wed, Aug 08, 2018 at 08:14:31PM +0200, Baptiste wrote: > > Hi Willy, > > > > Could you please also backport those patches to 1.8? > > Actually, 1.8 broke a haproxy's default behavior (when multiple servers > > shares the same hostname) and that this patch helps fixing. > > > > here is the commit: 8e2d9430c0562ed74276d7f58e92706c384c0a36 > > As you know usually we don't backport features (been burnt too much in > 1.5), but here if it fixes a regression, I guess it's a bit different. > I've had a new look at the code and it looks safe. > > However could you please explain a bit more what exactly changed and > how this broke, so that we can add the explanation in the backport > commit message ? It's important because if anyone later faces an issue, > we'll have to decide if we need to keep it or to revert, and in this > case to know what it's supposed to fix. > > Until HAProxy 1.7, the DNS resolver was able to allocate the same IP address to all (or a portion of) servers sharing the same hostname and being in the same backend. This behavior annoyed the people who wants to scale based on DNS response, hence we introduced prevention of duplication of IP addresses for servers sharing the same hostname and being in the same backend. So we fixed it in 1.8 with no possibility no "disable" this behavior. There are still some use cases where people may want to use the same IP address for multiple servers (they are running several instances of the same application on a server but on different ports, they use the same dev server several times in the backend, etc...). So this patch doesn't change default behavior introduced in 1.8 while allowing to change it when required. Baptiste
Re: [PATCH][MINOR] Implement resovle-opts with 2 new options
Hi Baptiste, On Wed, Aug 08, 2018 at 08:14:31PM +0200, Baptiste wrote: > Hi Willy, > > Could you please also backport those patches to 1.8? > Actually, 1.8 broke a haproxy's default behavior (when multiple servers > shares the same hostname) and that this patch helps fixing. > > here is the commit: 8e2d9430c0562ed74276d7f58e92706c384c0a36 As you know usually we don't backport features (been burnt too much in 1.5), but here if it fixes a regression, I guess it's a bit different. I've had a new look at the code and it looks safe. However could you please explain a bit more what exactly changed and how this broke, so that we can add the explanation in the backport commit message ? It's important because if anyone later faces an issue, we'll have to decide if we need to keep it or to revert, and in this case to know what it's supposed to fix. > Note the other patches have not been backported, and should have been: > 84221b4e9010810cf93b7ad7a31d825fa9fc26bf > 741e00a820ca23d3371a10587f5014c58ac14536 > e56fffd896fc29f886d5c55dc0930dc7e454b3c8 Thanks for the pointers. None of them was marked BUG, and no other one was marked as depending on them, that's why they were not spotted during the maintenance review cycle. Just checked, the last two are only cleanups, adjustments for comments or the removal of an unused macro, so they are not needed there at all. The first one was just backported however. Thanks! Willy
100% cpu usage 1.9-dev0-48d92ee 2018/07/30, task.?. but keeps working.. (nbthread 1)
Hi List, Ive got a weird issue.. and im not sure where/how to continue digging at the moment... Using nbthread=1 nbproc=1, a few lua scripts, ssl offloading / http traffic.. Only a few connections < 100... Sometimes haproxy starts using 100% cpu usage.. After a few days.. (Makes it hard to debug..) Currently running with version 'HA-Proxy version 1.9-dev0-48d92ee 2018/07/30' Ive ran some commands against the haproxy socket like 'show activity', as can be seen there are lots of loops and tasks in just a second of time. [2.4.3-RELEASE][root@pfsense_3]/root: /usr/local/pkg/haproxy/haproxy_socket.sh show activity show activity thread_id: 0 date_now: 1533754729.799405 loops: 828928664 wake_cache: 845396 wake_tasks: 827400248 wake_signal: 0 poll_exp: 828245644 poll_drop: 17451 poll_dead: 0 poll_skip: 0 fd_skip: 0 fd_lock: 0 fd_del: 0 conn_dead: 0 stream: 101147 empty_rq: 1242050 long_rq: 0 [2.4.3-RELEASE][root@pfsense_3]/root: /usr/local/pkg/haproxy/haproxy_socket.sh show activity show activity thread_id: 0 date_now: 1533754731.084664 loops: 829000230 wake_cache: 845398 wake_tasks: 827471812 wake_signal: 0 poll_exp: 828317210 poll_drop: 17452 poll_dead: 0 poll_skip: 0 fd_skip: 0 fd_lock: 0 fd_del: 0 conn_dead: 0 stream: 101149 empty_rq: 1242050 long_rq: 0 Other than that ive tried to attach gdb and step through / log some functions.. it passes through. With a gdb 'command' file like bellow i created a little log of function breakpoints hit: set pagination off set height 0 set logging on delete rbreak haproxy.c:. rbreak session.c:. rbreak hlua.c:. rbreak task.c:. commands 1-9 cont end cont Which got me a log with the following content.. as you can see it 'seems' to be looping over the same task multiple times.., which might not even be a problem.??. the t=0x802545a60 expires and wakes up , expires and wakes up.?.: Breakpoint 249, __task_queue (task=0x802545a60) at src/task.c:185 185 src/task.c: No such file or directory. Breakpoint 253, wake_expired_tasks () at src/task.c:209 209 in src/task.c Breakpoint 250, __task_wakeup (t=0x802545a60, root=0x8ced50 ) at src/task.c:72 72 in src/task.c Breakpoint 41, sync_poll_loop () at src/haproxy.c:2378 2378 src/haproxy.c: No such file or directory. Breakpoint 252, process_runnable_tasks () at src/task.c:275 275 src/task.c: No such file or directory. Breakpoint 51, session_expire_embryonic (t=0x802545a60, context=0x8024483a0, state=513) at src/session.c:389 389 src/session.c: No such file or directory. Breakpoint 249, __task_queue (task=0x802545a60) at src/task.c:185 185 src/task.c: No such file or directory. Breakpoint 253, wake_expired_tasks () at src/task.c:209 209 in src/task.c Breakpoint 250, __task_wakeup (t=0x802545a60, root=0x8ced50 ) at src/task.c:72 72 in src/task.c Breakpoint 41, sync_poll_loop () at src/haproxy.c:2378 2378 src/haproxy.c: No such file or directory. Breakpoint 252, process_runnable_tasks () at src/task.c:275 275 src/task.c: No such file or directory. Breakpoint 51, session_expire_embryonic (t=0x802545a60, context=0x8024483a0, state=513) at src/session.c:389 389 src/session.c: No such file or directory. Breakpoint 249, __task_queue (task=0x802545a60) at src/task.c:185 185 src/task.c: No such file or directory. Breakpoint 253, wake_expired_tasks () at src/task.c:209 209 in src/task.c Breakpoint 250, __task_wakeup (t=0x802545a60, root=0x8ced50 ) at src/task.c:72 72 in src/task.c Breakpoint 41, sync_poll_loop () at src/haproxy.c:2378 2378 src/haproxy.c: No such file or directory. Breakpoint 252, process_runnable_tasks () at src/task.c:275 275 src/task.c: No such file or directory. Breakpoint 51, session_expire_embryonic (t=0x802545a60, context=0x8024483a0, state=513) at src/session.c:389 389 src/session.c: No such file or directory. Breakpoint 249, __task_queue (task=0x802545a60) at src/task.c:185 185 src/task.c: No such file or directory. Breakpoint 253, wake_expired_tasks () at src/task.c:209 209 in src/task.c Breakpoint 250, __task_wakeup (t=0x802545a60, root=0x8ced50 ) at src/task.c:72 72 in src/task.c Breakpoint 41, sync_poll_loop () at src/haproxy.c:2378 2378 src/haproxy.c: No such file or directory. Breakpoint 252, process_runnable_tasks () at src/task.c:275 275 src/task.c: No such file or directory. Breakpoint 51, session_expire_embryonic (t=0x802545a60, context=0x8024483a0, state=513) at src/session.c:389 389 src/session.c: No such file or directory. Breakpoint 249, __task_queue (task=0x802545a60) at src/task.c:185 185 src/task.c: No such file or directory. Breakpoint 253, wake_expired_tasks () at src/task.c:209 209 in src/task.c Breakpoint 250, __task_wakeup (t=0x802545a60, root=0x8ced50 ) at src/task.c:72 72 in src/task.c Breakpoint 41, sync_poll_loop () at src/haproxy.c:2378 2378 src/haproxy.c: No such file or directory. Breakpoint 252, process_runnable_tasks () at
Re: Possible bug: configuration check is not checking resolvers
On Tue, Aug 7, 2018 at 2:14 PM, Marcos Moreno wrote: > Dear list members, > > I am not sure if this can be filed as a bug, but we are always eager to > contribute, and we had just an issue with a production server and wanted > that more experienced eyes had an opinion: > > While creating a config, we have a server with the following configuration: > > server myserver1 supercool-dockercontainer:80 check resolvers > docker_resolver resolve-prefer ipv4 > > Somehow we missed to put the "resolvers docker_resolver" configuration in > the configuration file, so it was totally missing. We mean: the following > was NOT in the config file: > resolvers docker_resolver > nameserver dns 127.0.0.11:53 > > However, by checking the configuration it was saying that the > configuration was fine. This is the commands we were using (yes, we are > sure this is the config file): > /usr/local/sbin/haproxy -c -V /usr/local/etc/haproxy/haproxy.cfg > > > First thing after running, haproxy sends an alert and dies: > [ALERT] 218/105233 (1) : config : backend 'mybacken1', server 'myserver1': > unable to find required resolvers 'docker_resolver' > > So obviously not having the resolver is an error that kills haproxy. > However, it was not found with a configuration check. > > Then the question: > -Was it the right way of checking the configuration? Missing some > parameter? > -If it was the right check, should it not be found by the configuration > checker command?--> So we found a small little bug?;-). > > Thanks and have a nice day, > Marcos Moreno. > Hi Marcos, Thanks for reporting this! You're testing procedure is the right one and I'm a bit suprised this is happening! I can also confirm I can reproduce this behavior and I will provide a fix soon. Baptiste
