Re: remaining process after (seamless) reload

2018-05-29 Thread Willy Tarreau
On Tue, May 29, 2018 at 08:35:19PM +0200, William Dauchy wrote: > I however don't see on which part haproxy would > need to do dns lookup on our side. Front end side is host matching and > backend side is IP only. We studied the possibility that a reload happends at the exact moment the config

Re: [PATCH][MINOR] config: Implement 'parse-resolv-conf' directive for resolvers

2018-05-29 Thread Willy Tarreau
On Tue, May 29, 2018 at 03:48:57PM -0600, Ben Draut wrote: > > > > So it looks all clean and works. > > That said, I would add a couple of tests on strdup you have: > > - newnameserver->conf.file = strdup("/etc/resolv.conf"); > > - newnameserver->id = strdup(address); > > and of course, I would

Re: [PATCH][MINOR] config: Implement 'parse-resolv-conf' directive for resolvers

2018-05-29 Thread Ben Draut
> > So it looks all clean and works. > That said, I would add a couple of tests on strdup you have: > - newnameserver->conf.file = strdup("/etc/resolv.conf"); > - newnameserver->id = strdup(address); > and of course, I would do the LIST_ADDQ after those checks. > Good catch, done. > Just fix

Re: remaining process after (seamless) reload

2018-05-29 Thread William Dauchy
Hello Tim, On Tue, May 29, 2018 at 9:33 PM, Tim Düsterhus wrote: > Run systemctl status haproxy. It shows the status: > >> [timwolla@/s/haproxy (maxrewrite-warn)]sudo systemctl status haproxy >> ● haproxy.service - HAProxy Load Balancer >>Loaded: loaded (/lib/systemd/system/haproxy.service;

Re: [PATCH][MINOR] config: Implement 'parse-resolv-conf' directive for resolvers

2018-05-29 Thread Baptiste
Hi Ben, Thanks! So it looks all clean and works. That said, I would add a couple of tests on strdup you have: - newnameserver->conf.file = strdup("/etc/resolv.conf"); - newnameserver->id = strdup(address); and of course, I would do the LIST_ADDQ after those checks. Just fix this and you get

Re: remaining process after (seamless) reload

2018-05-29 Thread Tim Düsterhus
William, Am 29.05.2018 um 17:09 schrieb William Dauchy: > We are using Type=notify. I however cannot guarantee we do not trigger > a new reload, before the previous one is done. Is there a way to check > the "ready" state you mentioned? Run systemctl status haproxy. It shows the status: >

Re: [PATCH][MINOR] config: Implement 'parse-resolv-conf' directive for resolvers

2018-05-29 Thread Ben Draut
This should be it. The only outstanding item was a couple of: if (... != NULL) free(...) at the bottom. Willy said he'd fix those up when he merged. On Tue, May 29, 2018 at 1:10 PM, Baptiste wrote: > Hi, > > I'm a bit lost: could you please re-send me the latest version of this > patch? > >

Re: [PATCH][MINOR] config: Implement 'parse-resolv-conf' directive for resolvers

2018-05-29 Thread Baptiste
Hi, I'm a bit lost: could you please re-send me the latest version of this patch? Baptiste On Thu, May 24, 2018 at 5:02 PM, Ben Draut wrote: > Willy, I think you've reviewed this one already. :) I fixed a few > things after your review, then you said you just wanted to wait > for Baptiste to

Re: remaining process after (seamless) reload

2018-05-29 Thread William Dauchy
Hello Dave, On Tue, May 29, 2018 at 5:55 PM, Dave Chiluk wrote: > We've battled the same issue with our haproxys. We root caused it to slow > dns lookup times while parsing the config was causing haproxy config parsing > to take so long that we were attempting to reload again before the

Re: Truly seamless reloads

2018-05-29 Thread Dave Chiluk
I backported the necessary patchset for seamless reloads on top of 1.7.9 a while back. It was used in production without issue for quite some time. I just rebased those patches on top of haproxy-1.7 development and pushed the result to seamless_reload branch that I pushed to github. They apply

Re: remaining process after (seamless) reload

2018-05-29 Thread Dave Chiluk
We've battled the same issue with our haproxys. We root caused it to slow dns lookup times while parsing the config was causing haproxy config parsing to take so long that we were attempting to reload again before the original reload had completed. I'm still not sure why or where the Signals are

Re: remaining process after (seamless) reload

2018-05-29 Thread William Dauchy
Hello William, Sorry for the last answer. > Are the problematical workers leaving when you reload a second time? no, they seems to stay for a long time (forever?) > Did you try to kill -USR1 the worker ? It should exits with "Former worker > $PID > exited with code 0" on stderr. > If not,

Re: Inquiry

2018-05-29 Thread Aleksandar Lazic
Hi. On 29/05/2018 14:30, Youssef George wrote: Dears, We are thinking about use HAproxy as loadblancer for our service that has huge traffic, So can you send to us some engineer in our site ( in Egypt ) to introduce HAproxy features to us and also the ways of support. If you have suppliers

Re: 100% cpu using resolvers with haproxy v1.8.9

2018-05-29 Thread Christopher Faulet
Le 29/05/2018 à 14:50, Olivier Houchard a écrit : Hi Stéphane, On Tue, May 29, 2018 at 12:38:40PM +0200, Stéphane Cottin wrote: Hi, This simple test config file : resolvers mydns nameserver ns1 10.0.0.1:53 listen mysql bind unix@/tmp/mysql.sock user www-data mode

Re: 100% cpu using resolvers with haproxy v1.8.9

2018-05-29 Thread Stéphane Cottin
Your patch fix this issue, thanks ! Stéphane On 29 May 2018, at 14:50, Olivier Houchard wrote: > Hi Stéphane, > > On Tue, May 29, 2018 at 12:38:40PM +0200, Stéphane Cottin wrote: >> Hi, >> >> This simple test config file : >> >> resolvers mydns >>nameserver ns1 10.0.0.1:53 >>

Re: 100% cpu using resolvers with haproxy v1.8.9

2018-05-29 Thread Olivier Houchard
Hi Stéphane, On Tue, May 29, 2018 at 12:38:40PM +0200, Stéphane Cottin wrote: > Hi, > > This simple test config file : > > resolvers mydns > nameserver ns1 10.0.0.1:53 > listen mysql > bind unix@/tmp/mysql.sock user www-data mode 600 > option mysql-check user haproxy

Inquiry

2018-05-29 Thread Youssef George
Dears, We are thinking about use HAproxy as loadblancer for our service that has huge traffic, So can you send to us some engineer in our site ( in Egypt ) to introduce HAproxy features to us and also the ways of support. If you have suppliers in Egypt kindly send their contacts to us. --

Re: 100% cpu using resolvers with haproxy v1.8.9

2018-05-29 Thread Stéphane Cottin
Hello William, Thanks for the patch, but applying it on 1.8.9 does not fix my issue. Stéphane On 29 May 2018, at 13:24, William Dauchy wrote: Hello Stephane, On Tue, May 29, 2018 at 12:38 PM, Stéphane Cottin wrote: This simple test config file : resolvers mydns nameserver ns1

Re: 100% cpu using resolvers with haproxy v1.8.9

2018-05-29 Thread William Dauchy
Hello Stephane, On Tue, May 29, 2018 at 12:38 PM, Stéphane Cottin wrote: > This simple test config file : > > resolvers mydns > nameserver ns1 10.0.0.1:53 > listen mysql > bind unix@/tmp/mysql.sock user www-data mode 600 > option mysql-check user haproxy post-41 > server MYSQL

100% cpu using resolvers with haproxy v1.8.9

2018-05-29 Thread Stéphane Cottin
Hi, This simple test config file : resolvers mydns nameserver ns1 10.0.0.1:53 listen mysql bind unix@/tmp/mysql.sock user www-data mode 600 option mysql-check user haproxy post-41 server MYSQL mysql.my.domain:3306 maxconn 100 check resolvers mydns makes