RE-VERIFY YOUR ACCOUNT (Final Warning)

[formilux . org]

帐户终止通知


我们想告诉你，你的电子邮件帐户将被关闭 
2018年3月15日




原因：您一直忽略您的更新通知



如果您想继续使用您的帐户，请立即更新以继续使用我们的服务：









点击这里更新您的帐户

注意:
 
忽略此讯息会导致您的电子邮件帐户在未经您许可的情况下 被终止。




谢谢
Email Admin © 2018
 

Re: add header into http-request redirect

[Tim Düsterhus]

Willy,

I'd like to bring this issue to your attention again, possibly you are
able to find a solution for haproxy 1.9?

This issue prevents me from submitting one domain to the HSTS preload
list, as I need to perform a redirect on the zone's apex and that
redirect does not include the HSTS header.

Best regards
Tim Düsterhus

Mailing list link of the quoted mail:
https://www.mail-archive.com/haproxy@formilux.org/msg25061.html

Am 28.02.2017 um 07:49 schrieb Willy Tarreau:
> On Sun, Feb 26, 2017 at 07:02:52PM +0100, thierry.fourn...@arpalert.org wrote:
>> Haproxy can't add header to a redirect because redirect is a final
>> directive. After executing the redirect no more action are executed.
> 
> We really need to think about it for the short term future because it's
> not the first time we need this. Having a few "header" directives on
> the "redirect" rules could help, but I already expect that everyone
> will want these ones to support dynamic log-formats etc...
> 
> In the mean time I think there is an alternate even uglier trick but
> I have not tested it :
> 
> http-request redirect location 
> "https://blah..\r\nStrict-Transport-Security: foobar"
> 
> The idea is that the string presented in "location" will be copy-pasted
> as-is in the Location header, so I guess that if it contains a CRLF it
> will be appended as is. Yes I know it's ugly and it would be better to
> support more flexible responses.
> 
> Cheers,
> Willy
> 

Re: [PATCH] BUG/MINOR: force-persist and ignore-persist only apply to backends

[Willy Tarreau]

On Mon, Mar 12, 2018 at 10:02:59PM +0100, Cyril Bonté wrote:
> From the very first day of force-persist and ignore-persist features,
> they only applied to backends, except that the documentation stated it
> could also be applied to frontends.
(...)

applied, thanks!
Willy

Re: [PATCH] BUG/MEDIUM: fix a 100% cpu usage with cpu-map and nbthread/nbproc

[Willy Tarreau]

On Mon, Mar 12, 2018 at 09:47:39PM +0100, Cyril Bonté wrote:
> Krishna Kumar reported a 100% cpu usage with a configuration using
> cpu-map and a high number of threads,
(...)

Patch applied, thank you Cyril!
Willy

[PATCH] BUG/MINOR: force-persist and ignore-persist only apply to backends

[Cyril Bonté]

>From the very first day of force-persist and ignore-persist features,
they only applied to backends, except that the documentation stated it
could also be applied to frontends.

In order to make it clear, the documentation is updated and the parser
will raise a warning if the keywords are used in a frontend section.

This patch should be backported up to the 1.5 branch.
---
 doc/configuration.txt | 8 
 src/cfgparse.c| 2 +-
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/doc/configuration.txt b/doc/configuration.txt
index a914c416c..992e18acc 100644
--- a/doc/configuration.txt
+++ b/doc/configuration.txt
@@ -2039,7 +2039,7 @@ errorloc  X  X
 X X
 errorloc302   X  X X X
 -- keyword -- defaults - frontend - listen -- backend -
 errorloc303   X  X X X
-force-persist -  X X X
+force-persist -  - X X
 filter-  X X X
 fullconn  X  - X X
 grace X  X X X
@@ -2052,7 +2052,7 @@ http-response -  X
 X X
 http-reuseX  - X X
 http-send-name-header -  - X X
 id-  X X X
-ignore-persist-  X X X
+ignore-persist-  - X X
 load-server-state-from-file   X  - X X
 log  (*)  X  X X X
 log-formatX  X X -
@@ -3503,7 +3503,7 @@ email-alert to 
 force-persist { if | unless } 
   Declare a condition to force persistence on down servers
   May be used in sections:defaults | frontend | listen | backend
-  no   |yes   |   yes  |   yes
+  no   |no|   yes  |   yes
 
   By default, requests are not dispatched to down servers. It is possible to
   force this using "option persist", but it is unconditional and redispatches
@@ -4825,7 +4825,7 @@ id 
 ignore-persist { if | unless } 
   Declare a condition to ignore persistence
   May be used in sections:defaults | frontend | listen | backend
-  no   |yes   |   yes  |   yes
+  no   |no|   yes  |   yes
 
   By default, when cookie persistence is enabled, every requests containing
   the cookie are unconditionally persistent (assuming the target server is up
diff --git a/src/cfgparse.c b/src/cfgparse.c
index 27d7eee7b..c40e71dc7 100644
--- a/src/cfgparse.c
+++ b/src/cfgparse.c
@@ -4068,7 +4068,7 @@ int cfg_parse_listen(const char *file, int linenum, char 
**args, int kwm)
goto out;
}
 
-   if (warnifnotcap(curproxy, PR_CAP_FE|PR_CAP_BE, file, linenum, 
args[0], NULL))
+   if (warnifnotcap(curproxy, PR_CAP_BE, file, linenum, args[0], 
NULL))
err_code |= ERR_WARN;
 
if (strcmp(args[1], "if") != 0 && strcmp(args[1], "unless") != 
0) {
-- 
2.11.0

Re: What is a nice way to bypass the maintenance mode for certain IP's?

[Cyril Bonté]

Hi Willy,

Le 02/03/2018 à 06:32, Willy Tarreau a écrit :

You're right, both are set in the same loop. Usually I prefer to adapt
the code to make it match the doc, but here I don't see a reasonable
way to do it, so I think we'll instead update the code to emit a warning
and update the doc. Any objection ?


With some delay, no objection at all. This is probably the safest option 
as it used to work like this since the beginning. I'm working on the patch.


--
Cyril Bonté

[PATCH] BUG/MEDIUM: fix a 100% cpu usage with cpu-map and nbthread/nbproc

[Cyril Bonté]

Krishna Kumar reported a 100% cpu usage with a configuration using
cpu-map and a high number of threads,

Indeed, this minimal configuration to reproduce the issue :
  global
nbthread 40
cpu-map auto:1/1-40 0-39

  frontend test
bind :8000

This is due to a wrong type in a shift operator (int vs unsigned long int),
causing an endless loop while applying the cpu affinity on threads. The same
issue may also occur with nbproc under FreeBSD. This commit addresses both
cases.

This patch must be backported to 1.8.
---
 src/haproxy.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/haproxy.c b/src/haproxy.c
index 8785b9f94..0c823c497 100644
--- a/src/haproxy.c
+++ b/src/haproxy.c
@@ -2837,7 +2837,7 @@ int main(int argc, char **argv)
CPU_ZERO();
while ((i = ffsl(cpu_map)) > 0) {
CPU_SET(i - 1, );
-   cpu_map &= ~(1 << (i - 1));
+   cpu_map &= ~(1UL << (i - 1));
}
ret = cpuset_setaffinity(CPU_LEVEL_WHICH, 
CPU_WHICH_PID, -1, sizeof(cpuset), );
}
@@ -3037,7 +3037,7 @@ int main(int argc, char **argv)
 
while ((j = ffsl(cpu_map)) > 0) {
CPU_SET(j - 1, );
-   cpu_map &= ~(1 << (j - 1));
+   cpu_map &= ~(1UL << (j - 1));
}
pthread_setaffinity_np(threads[i],
   sizeof(cpuset), );
-- 
2.11.0

Re: Idle HAProxy 1.8 spins at 100% in user space

[Cyril Bonté]

Le 12/03/2018 à 14:11, Krishna Kumar (Engineering) a écrit :

Hi Cyril,

Thanks, this patch fixes it, it is now back to 0%. Confirmed it a few
times, and undid the patch, back to 100%, and re-added the patch,
back to 0%. Fixes perfectly.


Thanks for confirming, I'm preparing the patch with a reasonable commit 
message. It should be ready in a few minutes ;-)



--
Cyril Bonté

RE: logger #n in ALERT messages?

[Glen Gunselman]

From: PiBa-NL [mailto:piba.nl@gmail.com]
Sent: Friday, March 9, 2018 3:08 PM
To: Glen Gunselman ; Haproxy 
Subject: Re: logger #n in ALERT messages?

Hi Glen,
Op 9-3-2018 om 17:43 schreef Glen Gunselman:

   (Note: this is my first attempt to setup haproxy, I'm using Oracle Linux 6.9 
and HA-Proxy version 1.5.18 2016/05/10)


How do I relate "logger #n" in ALERT messages to the configuration statements?


Related details:

>From starting haproxy using:
sudo haproxy -d -f /etc/haproxy/haproxy.cfg | grep logger

I get ALERTs of the following format:

[ALERT] 067/101928 (39878) : sendto logger #2 failed: Resource temporarily 
unavailable (errno=11)
[ALERT] 067/101928 (39878) : sendto logger #1 failed: No such file or directory 
(errno=2)
[ALERT] 067/101928 (39878) : sendto logger #2 failed: No such file or directory 
(errno=2)
[ALERT] 067/101928 (39878) : sendto logger #1 failed: No such file or directory 
(errno=2)
...


>From top of /etc/haproxy/haproxy.cfg

global
  log /dev/loglocal0
  log /dev/loglocal1 notice
  chroot /var/lib/haproxy
You do have both log sockets?:
  /dev/log
and
  /var/lib/haproxy/dev/log
[Glen Gunselman]

NO, only /dev/log


  user haproxy
  group haproxy
  daemon
  maxconn 1
  stats socket /var/run/haproxy/haproxy.sock mode 0600 level admin

  # Default SSL material locations
  ca-base /etc/ssl/certs
  crt-base /etc/ssl/private
  tune.ssl.default-dh-param 2048
  ssl-default-bind-ciphers 
kEECDH+aRSA+AES:kRSA+AES:+AES256:!kEDH:!LOW:!EXP:!MD5:!aNULL:!eNULL
  ssl-default-bind-options no-sslv3

defaults
  log global
  modehttp
  option  httplog
  option  dontlognull
  option  forwardfor
  timeout connect 5000
  timeout client 300s
  timeout server 300s

listen  stats   :1936
modehttp
log global

maxconn 10

timeout client  100s
timeout server  100s
timeout connect 100s
timeout queue   100s

stats enable
stats hide-version
stats refresh 30s
stats show-node
stats auth :
stats uri  /haproxy?stats


(Note: I did not include the frontend, acl, use_backend and backend sections.  
There are no log statements in these sections.)


I did add the following to /etc/rsyslog.conf and messages are being logged to 
those files.

local0.*   /var/log/haproxy.log
local1.*   
/var/log/haproxy-status.log


Thanks for any clues,
Glen



Regards,

PiBa-NL (Pieter)

Re: Idle HAProxy 1.8 spins at 100% in user space

[Krishna Kumar (Engineering)]

Hi Cyril,

Thanks, this patch fixes it, it is now back to 0%. Confirmed it a few
times, and undid the patch, back to 100%, and re-added the patch,
back to 0%. Fixes perfectly.

Thanks,
- Krishna


On Mon, Mar 12, 2018 at 5:23 PM, Willy Tarreau  wrote:

> On Mon, Mar 12, 2018 at 12:36:05PM +0100, Cyril Bonté wrote:
> > I confirm I can reproduce the issue once 32 (and more) threads are used
> : the main process enters an endless loop.
> > I think the same issue may occur with nbproc on FreeBSD (the same code
> in an #ifdef FreeBSD__).
> >
> > Can you try the patch attached ? I'll send a clean one later.
>
> Ah good catch, I'm pretty sure you nailed it down indeed! The fun thing
> is that the initial purpose of that patch was precisely to avoid this
> kind of annoying stuff in the first place!
>
> Cheers,
> Willy
>

Re: Idle HAProxy 1.8 spins at 100% in user space

[Willy Tarreau]

On Mon, Mar 12, 2018 at 12:36:05PM +0100, Cyril Bonté wrote:
> I confirm I can reproduce the issue once 32 (and more) threads are used : the 
> main process enters an endless loop.
> I think the same issue may occur with nbproc on FreeBSD (the same code in an 
> #ifdef FreeBSD__).
> 
> Can you try the patch attached ? I'll send a clean one later.

Ah good catch, I'm pretty sure you nailed it down indeed! The fun thing
is that the initial purpose of that patch was precisely to avoid this
kind of annoying stuff in the first place!

Cheers,
Willy

Re: Idle HAProxy 1.8 spins at 100% in user space

[Cyril Bonté]

Hi Krishna and Willy, 

- Mail original -
> De: "Krishna Kumar (Engineering)" 
> À: "HAProxy" 
> Envoyé: Lundi 12 Mars 2018 07:48:50
> Objet: Idle HAProxy 1.8 spins at 100% in user space
> 
> As an aside, could someone also post a simple configuration file to
> enable 40 listeners (thread)?
> 
> I get 100% cpu util when running high number (>30, on a 48 core
> system)
> of threads, I have tried both these versions:
> 
> HA-Proxy version 1.8.4-1ppa1~xenial 2018/02/10: Installed via .deb
> file
> HA-Proxy version 1.8.4-1deb90d 2018/02/08: Built from source
> http://www.haproxy.org/download/1.8/src/haproxy-1.8.4.tar.gz
> 
> 1. Distro/kernel: Ubuntu 16.04.1 LTS, 4.4.0-36-generic
> 
> 
> 2. Top:
> # top -d 1 -b | head -12
> top - 11:59:06 up 4 days, 41 min, 1 user, load average: 1.00, 1.00,
> 2.14
> Tasks: 492 total, 2 running, 464 sleeping, 0 stopped, 26 zombie
> %Cpu(s): 0.5 us, 0.2 sy, 0.0 ni, 99.2 id, 0.0 wa, 0.0 hi, 0.1 si, 0.0
> st
> KiB Mem : 13191999+total, 9520 free, 1222684 used, 52917792
> buff/cache
> KiB Swap: 0 total, 0 free, 0 used. 12986652+avail Mem
> 
> 
> PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
> 87994 haproxy 20 0 896624 14996 1468 R 100.0 0.0 3:09.60 haproxy
> 1 root 20 0 38856 7088 4132 S 0.0 0.0 0:08.69 systemd
> 2 root 20 0 0 0 0 S 0.0 0.0 0:00.08 kthreadd
> 3 root 20 0 0 0 0 S 0.0 0.0 4:05.79 ksoftirqd/0
> 5 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 kworker/0:0H
> 
> 
> 3. As to what it is doing:
> %Cpu0 :100.0 us, 0.0 sy, 0.0 ni, 0.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0
> st
> 
> 
> %Cpu1 : 0.0 us, 0.0 sy, 0.0 ni,100.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0
> st
> %Cpu2 : 0.0 us, 0.0 sy, 0.0 ni,100.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0
> st
> 
> 
> 4. Minimal configuration file to reproduce this (using this blog:
> https://www.haproxy.com/blog/multithreading-in-haproxy/ ):
> 
> 
> 
> global
> daemon
> nbproc 1
> nbthread 40
> cpu-map auto:1/1-40 0-39

I confirm I can reproduce the issue once 32 (and more) threads are used : the 
main process enters an endless loop.
I think the same issue may occur with nbproc on FreeBSD (the same code in an 
#ifdef FreeBSD__).

Can you try the patch attached ? I'll send a clean one later.

> 
> 
> frontend test-fe
> mode http
> bind 10.33.110.118:80 process all/all
> use_backend test-be
> 
> 
> backend test-be
> mode http
> server 10.33.5.62 10.33.5.62:80 weight 255
> 
> 
> 5. Problem disappears when " cpu-map auto:1/1-40 0-39" is commented
> out.
> Same strace output, so it is in user space as shown by 'top' above.
> 
> 
> 6. Version/build (gcc version 5.4.0 20160609 (Ubuntu
> 5.4.0-6ubuntu1~16.04.2))
> 
> 
> 
> # haproxy -vv
> HA-Proxy version 1.8.4-1deb90d 2018/02/08
> Copyright 2000-2018 Willy Tarreau < wi...@haproxy.org >
> 
> 
> Build options :
> TARGET = linux2628
> CPU = generic
> CC = gcc
> CFLAGS = -O2 -g -fno-strict-aliasing -Wdeclaration-after-statement
> -fwrapv -Wno-unused-label
> OPTIONS = USE_ZLIB=yes USE_OPENSSL=1 USE_PCRE=1
> 
> 
> Default settings :
> maxconn = 2000, bufsize = 16384, maxrewrite = 1024, maxpollevents =
> 200
> 
> 
> Built with OpenSSL version : OpenSSL 1.0.2g 1 Mar 2016
> Running on OpenSSL version : OpenSSL 1.0.2g 1 Mar 2016
> OpenSSL library supports TLS extensions : yes
> OpenSSL library supports SNI : yes
> OpenSSL library supports : TLSv1.0 TLSv1.1 TLSv1.2
> Built with transparent proxy support using: IP_TRANSPARENT
> IPV6_TRANSPARENT IP_FREEBIND
> Encrypted password support via crypt(3): yes
> Built with multi-threading support.
> Built with PCRE version : 8.38 2015-11-23
> Running on PCRE version : 8.38 2015-11-23
> PCRE library supports JIT : no (USE_PCRE_JIT not set)
> Built with zlib version : 1.2.8
> Running on zlib version : 1.2.8
> Compression algorithms supported : identity("identity"),
> deflate("deflate"), raw-deflate("deflate"), gzip("gzip")
> Built with network namespace support.
> 
> 
> Available polling systems :
> epoll : pref=300, test result OK
> poll : pref=200, test result OK
> select : pref=150, test result OK
> Total: 3 (3 usable), will use epoll.
> 
> 
> Available filters :
> [SPOE] spoe
> [COMP] compression
> [TRACE] trace
> 
> 
> 7. Strace of the process:
> 88033 11:57:18.946030 <... epoll_wait resumed> [], 200, 1000) = 0
> <1.001144>
> 88032 11:57:18.946046 <... epoll_wait resumed> [], 200, 1000) = 0
> <1.001149>
> 88033 11:57:18.946078 epoll_wait(47, 
> 88034 11:57:18.946092 epoll_wait(48, 
> 88032 11:57:18.946104 epoll_wait(46, 
> 88031 11:57:18.946115 <... epoll_wait resumed> [], 200, 1000) = 0
> <1.001153>
> 88030 11:57:18.946128 <... epoll_wait resumed> [], 200, 1000) = 0
> <1.001154>
> 88029 11:57:18.946140 <... epoll_wait resumed> [], 200, 1000) = 0
> <1.001155>
> 88028 11:57:18.946152 <... epoll_wait resumed> [], 200, 1000) = 0
> <1.001216>
> 88031 11:57:18.946169 epoll_wait(44, 
> 88027 11:57:18.946181 <... epoll_wait resumed> [], 200, 1000) = 0
> <1.001183>
> 88030 11:57:18.946196 epoll_wait(43, 
> 88029 11:57:18.946208 

Re: Updating the unofficial GitHub mirror

[Georg Faerber]

On 18-03-12 07:22:22, Dan Kohn wrote:
> >
> > On Mon, Mar 12, 2018 at 10:42:30AM +0100, Pavlos Parissis wrote:
> > > Have you asked the maintainer of the github fork to change the project to
> > > 'unofficial-haproxy' or something else?
> >
> 
> On Mon, Mar 12, 2018 at 6:15 AM, Willy Tarreau  wrote:
> 
> > Yes, and he's not opposed to it, he just doesn't have much time to deal
> > with this. In short we "just" have to move this repository somewhere
> > else, possibly on his personal account, and reuse it to periodically
> > push updates. Now that Lukas has purged all issues and pull requests,
> > I'd say that there is not much showstopper to do it. I simply have no
> > idea how to proceed from here :-/
> >
> 
> We've set up our scraper to make use of GitHub and GitHub mirrors rather
> than being able to access any git repo.

I guess I won't be the only one being happy to see this policy revisited
(and changed).

Seriously: The "Linux Foundation" should to better.

Cheers,
Georg


signature.asc
Description: Digital signature

Re: Updating the unofficial GitHub mirror

[Willy Tarreau]

On Mon, Mar 12, 2018 at 07:22:22AM -0400, Dan Kohn wrote:
> >
> > On Mon, Mar 12, 2018 at 10:42:30AM +0100, Pavlos Parissis wrote:
> > > Have you asked the maintainer of the github fork to change the project to
> > > 'unofficial-haproxy' or something else?
> >
> 
> On Mon, Mar 12, 2018 at 6:15 AM, Willy Tarreau  wrote:
> 
> > Yes, and he's not opposed to it, he just doesn't have much time to deal
> > with this. In short we "just" have to move this repository somewhere
> > else, possibly on his personal account, and reuse it to periodically
> > push updates. Now that Lukas has purged all issues and pull requests,
> > I'd say that there is not much showstopper to do it. I simply have no
> > idea how to proceed from here :-/
> >
> 
> We've set up our scraper to make use of GitHub and GitHub mirrors rather
> than being able to access any git repo.

OK.

> Would it be possible for you to connect me to the owner of the haproxy
> mirror ?

Sure, I'll give you all this off-list.

> We have a good relationship with
> GitHub, and GitHub might be willing to take over the mirror and get it up
> to date again.

Great. We have some good contacts as well (some even on this list), helping
us improve the situation at the beginning, but due to the number of pending
issues and pull-reqs, we didn't want to break everything by then, and since
we've fixed this we haven't made progress (mostly by lack of demand I'd say).
Your argument above is a good reason to complete the move.

> Note that GitHub currently mirrors a number of projects <
> https://help.github.com/articles/about-github-mirrors/>.

That could even be easier to set up, I didn't know.

> And that GitHub is
> an HAProxy user <
> https://githubengineering.com/glb-part-2-haproxy-zero-downtime-zero-delay-reloads-with-multibinder/

Yep, we're well aware :-)

Cheers,
Willy

Re: Updating the unofficial GitHub mirror

[Dan Kohn]

>
> On Mon, Mar 12, 2018 at 10:42:30AM +0100, Pavlos Parissis wrote:
> > Have you asked the maintainer of the github fork to change the project to
> > 'unofficial-haproxy' or something else?
>

On Mon, Mar 12, 2018 at 6:15 AM, Willy Tarreau  wrote:

> Yes, and he's not opposed to it, he just doesn't have much time to deal
> with this. In short we "just" have to move this repository somewhere
> else, possibly on his personal account, and reuse it to periodically
> push updates. Now that Lukas has purged all issues and pull requests,
> I'd say that there is not much showstopper to do it. I simply have no
> idea how to proceed from here :-/
>

We've set up our scraper to make use of GitHub and GitHub mirrors rather
than being able to access any git repo.

Would it be possible for you to connect me to the owner of the haproxy
mirror ? We have a good relationship with
GitHub, and GitHub might be willing to take over the mirror and get it up
to date again. Note that GitHub currently mirrors a number of projects <
https://help.github.com/articles/about-github-mirrors/>. And that GitHub is
an HAProxy user <
https://githubengineering.com/glb-part-2-haproxy-zero-downtime-zero-delay-reloads-with-multibinder/
>.
--
Dan Kohn 
Executive Director, Cloud Native Computing Foundation https://www.cncf.io
+1-415-233-1000 https://www.dankohn.com

Re: stats page: inconsistent numbers spacing (thousands)

[Willy Tarreau]

On Mon, Mar 12, 2018 at 11:09:00AM +0200, John Cherouvim wrote:
> Hello Willy
> 
> I understand the need for spacing. My message was only regarding the
> inconsistent usage of it (e.g "2" vs "2 000"). Anyway, it's not
> important, just something I found out and thought it was worth mentioning.

You're right, and possibly that it deserves being addressed if there are
only a few areas left. After all it's mostly used for counters and there
are not that many ;-)

Do you want to take a look at the code and see if you can fix it yourself
and provide a patch ? It should be in src/stats.c. If you're interested in
taking a look at it, please read CONTRIBUTING before submitting your patch,
in order to see how to format it and help you provide a good one on the
first attempt.

Cheers,
Willy

Re: Updating the unofficial GitHub mirror

[Willy Tarreau]

Hi Pavlos,

On Mon, Mar 12, 2018 at 10:42:30AM +0100, Pavlos Parissis wrote:
> Have you asked the maintainer of the github fork to change the project to
> 'unofficial-haproxy' or something else?

Yes, and he's not opposed to it, he just doesn't have much time to deal
with this. In short we "just" have to move this repository somewhere
else, possibly on his personal account, and reuse it to periodically
push updates. Now that Lukas has purged all issues and pull requests,
I'd say that there is not much showstopper to do it. I simply have no
idea how to proceed from here :-/

Willy

Re: Updating the unofficial GitHub mirror

[Pavlos Parissis]

On 12/03/2018 08:07 πμ, Willy Tarreau wrote:
> Hi Dan,
> 
> On Sun, Mar 11, 2018 at 12:55:59PM -0400, Dan Kohn wrote:
>> I'm the author of the CNCF Cloud Native Interactive Landscape, which tracks 
>> projects and
>> products used in open source. We include HAProxy:
>> 
>> https://landscape.cncf.io/grouping=no=ha-proxy=latest-commit
>> 
>> However, our info on latest commit is out of date because 
>> https://github.com/haproxy/haproxy is
>> no longer mirroring http://www.haproxy.org/. Would it be possible to update 
>> the mirror,
>> please?
> 
> The Github link above is not a mirror, it's an unofficial fork with a few 
> local patches which has
> already caused some confusion in the past as it was receiving issues and pull 
> requests that were
> ignored.

Have you asked the maintainer of the github fork to change the project to 
'unofficial-haproxy' or
something else?

Cheers,
Pavlos



signature.asc
Description: OpenPGP digital signature

Re: stats page: inconsistent numbers spacing (thousands)

[John Cherouvim]

Hello Willy

I understand the need for spacing. My message was only regarding the 
inconsistent usage of it (e.g "2" vs "2 000"). Anyway, it's not 
important, just something I found out and thought it was worth mentioning.


Thanks for answering this and, in general, for your great software.
John



Willy Tarreau wrote:

Hello John,

On Fri, Mar 02, 2018 at 01:04:11PM +0200, John Cherouvim wrote:
  

Hello

My stats page (haproxy version: 1.8.4-1ppa1~xenial) shows some values as
"2" and others as "2 000" (note the thousands spacing). The CSV in
question shows the numbers without spaces:


backend_varnish,varnish,0,0,0,0,2,0,0,0,,0,,0,0,0,0,no 
check,1,1,0,,,92203,,,1,3,1,,0,,2,0,,00,0,0,0,0,0,0,0,-1,,,0,0,0,0,,http
backend_varnish,BACKEND,0,0,0,0,2000,0,0,0,0,0,,0,0,0,0,UP,1,1,0,,0,92203,0,,1,3,0,,0,,1,0,,00,0,0,0,0,00,0,0,0,0,0,0,-1,,,0,0,0,0,,http
  

Also, in the errors section it shows "25 131" (has space) in Errors > Conns
but "213832" (no space) in Warnings > Retr.

Is this an HTML templating bug of the stats page? Or is there a reason for
this kind of presentation?



It should not be a bug, the spacing is intentional to make large numbers more
readable. It's really important when you are looking at a large page with tens
of servers showing very large numbers. To give you an idea, a server delivering
10 Gbps of traffic will emit half a petabyte per week, and these numbers are
too large to remain readable. I tried to use larger units but that makes them
not move anymore (eg: for servers remaining up for a very long time), so in the
end, visually splitting the numbers seems like the best solution. It's possible
that it's not applied to every single number, as some such as connection errors
or retries are hardly supposed to be large. The way the spacing is done ensures
that you can still select the number and copy-paste it anywhere without copying
the spaces (eg for calculations). Ideally we should have small spaces on every
possibly large number.

Hoping this helps,
Willy

  

Re: 100% cpu usage after reload (USR2) with "bind abns@...."

[Christopher Faulet]

Le 05/03/2018 à 21:06, Dennis Jacobfeuerborn a écrit :

Hi,
today I started experimenting with the HAProxy 1.8.4 release and ran
into a Problem when it comes to reloading the configuration (USR2).
I'm running the release tarball via RPM on a CentOS 7 System in
master-worker mode and every time I perform a "systemctl reload" the
worker process suddenly uses 100% cpu and can only be killed via "kill -9".
Once I do so the old processes go away and two new ones show up and
everything goes back to normal.

After reducing the config bit by bit I was able to isolate the config
that is causing this:

bind abns@haproxy-ssl accept-proxy

Once I replace the "abns@haproxy-ssl" bit with an ip:port combination
the problem goes away so it seems the "abns@" part is the culprit here.

Regards,
   Dennis



Hi Dennis,

A recent commit could fix your problem:

  http://git.haproxy.org/?p=haproxy.git;a=commitdiff;h=ec9516a6

It was pushed in upstream and will be backported in 1.8. Could you check 
if it works please ?


--
Christopher Faulet

Re: Haproxy 1.7.10 constantly restarting

[Georg Faerber]

Hi Aleksey,

On 18-03-12 07:04:05, Aleksey Gordeev wrote:
> Thank you for answer. Sorry for stupid question. Found it. I forget
> about letsencrypt. it restarts when renewing certificates.

Change it so it does only restart after renewing. I guess, Most of time
it only checks, but doesn't renew.

All the best,
Georg


signature.asc
Description: Digital signature

Re: Updating the unofficial GitHub mirror

[Willy Tarreau]

Hi Dan,

On Sun, Mar 11, 2018 at 12:55:59PM -0400, Dan Kohn wrote:
> I'm the author of the CNCF Cloud Native Interactive Landscape, which tracks
> projects and products used in open source. We include HAProxy:
> 
> https://landscape.cncf.io/grouping=no=ha-proxy=latest-commit
> 
> However, our info on latest commit is out of date because
> https://github.com/haproxy/haproxy is no longer mirroring
> http://www.haproxy.org/. Would it be possible to update the mirror, please?

The Github link above is not a mirror, it's an unofficial fork with a few
local patches which has already caused some confusion in the past as it
was receiving issues and pull requests that were ignored.

The correct Git URLs are :

http://git.haproxy.org/git/haproxy.git/(development tree)
http://git.haproxy.org/git/haproxy-1.8.git/(1.8 stable tree)

Hoping this helps,
Willy

Re: stats page: inconsistent numbers spacing (thousands)

[Willy Tarreau]

Hello John,

On Fri, Mar 02, 2018 at 01:04:11PM +0200, John Cherouvim wrote:
> Hello
> 
> My stats page (haproxy version: 1.8.4-1ppa1~xenial) shows some values as
> "2" and others as "2 000" (note the thousands spacing). The CSV in
> question shows the numbers without spaces:
> > backend_varnish,varnish,0,0,0,0,2,0,0,0,,0,,0,0,0,0,no 
> > check,1,1,0,,,92203,,,1,3,1,,0,,2,0,,00,0,0,0,0,0,0,0,-1,,,0,0,0,0,,http
> > backend_varnish,BACKEND,0,0,0,0,2000,0,0,0,0,0,,0,0,0,0,UP,1,1,0,,0,92203,0,,1,3,0,,0,,1,0,,00,0,0,0,0,00,0,0,0,0,0,0,-1,,,0,0,0,0,,http
> 
> Also, in the errors section it shows "25 131" (has space) in Errors > Conns
> but "213832" (no space) in Warnings > Retr.
> 
> Is this an HTML templating bug of the stats page? Or is there a reason for
> this kind of presentation?

It should not be a bug, the spacing is intentional to make large numbers more
readable. It's really important when you are looking at a large page with tens
of servers showing very large numbers. To give you an idea, a server delivering
10 Gbps of traffic will emit half a petabyte per week, and these numbers are
too large to remain readable. I tried to use larger units but that makes them
not move anymore (eg: for servers remaining up for a very long time), so in the
end, visually splitting the numbers seems like the best solution. It's possible
that it's not applied to every single number, as some such as connection errors
or retries are hardly supposed to be large. The way the spacing is done ensures
that you can still select the number and copy-paste it anywhere without copying
the spaces (eg for calculations). Ideally we should have small spaces on every
possibly large number.

Hoping this helps,
Willy

Re: [PATCH 3/3] CLEANUP: cli: Fix a typo in the 'set rate-limit' usage

[Willy Tarreau]

On Sun, Mar 11, 2018 at 08:27:42PM +0100, Aurélien Nephtali wrote:
> Hello,
> 
> The attached patch fixes a typo in the usage message of 'set
> rate-limit'.

Thank you Aurélien. I've applied all of your 4 patches. I've retagged
this last one "BUG/MINOR" since it the help message is wrong and the
fix needs to be backported.

Willy

Idle HAProxy 1.8 spins at 100% in user space

[Krishna Kumar (Engineering)]

As an aside, could someone also post a simple configuration file to
enable 40 listeners (thread)?

I get 100% cpu util when running high number (>30, on a 48 core system)
of threads, I have tried both these versions:

HA-Proxy version 1.8.4-1ppa1~xenial 2018/02/10: Installed via .deb file
HA-Proxy version 1.8.4-1deb90d 2018/02/08: Built from source
 http://www.haproxy.org/download/1.8/src/haproxy-1.8.4.tar.gz


1. Distro/kernel: Ubuntu 16.04.1 LTS, 4.4.0-36-generic

2. Top:
# top -d 1 -b  | head -12
top - 11:59:06 up 4 days, 41 min,  1 user,  load average: 1.00, 1.00, 2.14
Tasks: 492 total,   2 running, 464 sleeping,   0 stopped,  26 zombie
%Cpu(s):  0.5 us,  0.2 sy,  0.0 ni, 99.2 id,  0.0 wa,  0.0 hi,  0.1 si,
0.0 st
KiB Mem : 13191999+total, 9520 free,  1222684 used, 52917792 buff/cache
KiB Swap:0 total,0 free,0 used. 12986652+avail Mem

   PID USER  PR  NIVIRTRESSHR S  %CPU %MEM TIME+ COMMAND
 87994 haproxy   20   0  896624  14996   1468 R 100.0  0.0   3:09.60 haproxy
 1 root  20   0   38856   7088   4132 S   0.0  0.0   0:08.69 systemd
 2 root  20   0   0  0  0 S   0.0  0.0   0:00.08
kthreadd
 3 root  20   0   0  0  0 S   0.0  0.0   4:05.79
ksoftirqd/0
 5 root   0 -20   0  0  0 S   0.0  0.0   0:00.00
kworker/0:0H

3.  As to what it is doing:
%Cpu0  :100.0 us,  0.0 sy,  0.0 ni,  0.0 id,  0.0 wa,  0.0 hi,  0.0 si,
0.0 st
%Cpu1  :  0.0 us,  0.0 sy,  0.0 ni,100.0 id,  0.0 wa,  0.0 hi,  0.0 si,
0.0 st
%Cpu2  :  0.0 us,  0.0 sy,  0.0 ni,100.0 id,  0.0 wa,  0.0 hi,  0.0 si,
0.0 st

4. Minimal configuration file to reproduce this (using this blog:
   https://www.haproxy.com/blog/multithreading-in-haproxy/):

global
daemon
nbproc 1
nbthread 40
cpu-map auto:1/1-40 0-39

frontend test-fe
mode http
bind 10.33.110.118:80 process all/all
use_backend test-be

backend test-be
mode http
server 10.33.5.62 10.33.5.62:80 weight 255

5. Problem disappears when "cpu-map auto:1/1-40 0-39" is commented out.
Same strace output, so it is in user space as shown by 'top' above.

6. Version/build (gcc version 5.4.0 20160609 (Ubuntu
5.4.0-6ubuntu1~16.04.2))

# haproxy -vv
HA-Proxy version 1.8.4-1deb90d 2018/02/08
Copyright 2000-2018 Willy Tarreau 

Build options :
  TARGET  = linux2628
  CPU = generic
  CC  = gcc
  CFLAGS  = -O2 -g -fno-strict-aliasing -Wdeclaration-after-statement
-fwrapv -Wno-unused-label
  OPTIONS = USE_ZLIB=yes USE_OPENSSL=1 USE_PCRE=1

Default settings :
  maxconn = 2000, bufsize = 16384, maxrewrite = 1024, maxpollevents = 200

Built with OpenSSL version : OpenSSL 1.0.2g  1 Mar 2016
Running on OpenSSL version : OpenSSL 1.0.2g  1 Mar 2016
OpenSSL library supports TLS extensions : yes
OpenSSL library supports SNI : yes
OpenSSL library supports : TLSv1.0 TLSv1.1 TLSv1.2
Built with transparent proxy support using: IP_TRANSPARENT IPV6_TRANSPARENT
IP_FREEBIND
Encrypted password support via crypt(3): yes
Built with multi-threading support.
Built with PCRE version : 8.38 2015-11-23
Running on PCRE version : 8.38 2015-11-23
PCRE library supports JIT : no (USE_PCRE_JIT not set)
Built with zlib version : 1.2.8
Running on zlib version : 1.2.8
Compression algorithms supported : identity("identity"),
deflate("deflate"), raw-deflate("deflate"), gzip("gzip")
Built with network namespace support.

Available polling systems :
  epoll : pref=300,  test result OK
   poll : pref=200,  test result OK
 select : pref=150,  test result OK
Total: 3 (3 usable), will use epoll.

Available filters :
[SPOE] spoe
[COMP] compression
[TRACE] trace

7. Strace of the process:
88033 11:57:18.946030 <... epoll_wait resumed> [], 200, 1000) = 0 <1.001144>
88032 11:57:18.946046 <... epoll_wait resumed> [], 200, 1000) = 0 <1.001149>
88033 11:57:18.946078 epoll_wait(47,  
88034 11:57:18.946092 epoll_wait(48,  
88032 11:57:18.946104 epoll_wait(46,  
88031 11:57:18.946115 <... epoll_wait resumed> [], 200, 1000) = 0 <1.001153>
88030 11:57:18.946128 <... epoll_wait resumed> [], 200, 1000) = 0 <1.001154>
88029 11:57:18.946140 <... epoll_wait resumed> [], 200, 1000) = 0 <1.001155>
88028 11:57:18.946152 <... epoll_wait resumed> [], 200, 1000) = 0 <1.001216>
88031 11:57:18.946169 epoll_wait(44,  
88027 11:57:18.946181 <... epoll_wait resumed> [], 200, 1000) = 0 <1.001183>
88030 11:57:18.946196 epoll_wait(43,  
88029 11:57:18.946208 epoll_wait(40,  
88028 11:57:18.946219 epoll_wait(39,  
88027 11:57:18.946231 epoll_wait(38,  
88026 11:57:18.946244 <... epoll_wait resumed> [], 200, 1000) = 0 <1.001296>
88025 11:57:18.946257 <... epoll_wait resumed> [], 200, 1000) = 0 <1.001248>
88024 11:57:18.946269 <... epoll_wait resumed> [], 200, 1000) = 0 <1.001226>
88023 11:57:18.946282 <... epoll_wait resumed> [], 200, 1000) = 0 <1.001210>
88026 11:57:18.946293 epoll_wait(37,  
88022 11:57:18.946307 <... epoll_wait resumed> [], 200, 1000) = 0 <1.001224>
88025 11:57:18.946320 epoll_wait(36,