talking http to a https port

2018-08-15 Thread Angelo Höngens
Hey guys,

I'm building a solution where I am ssl-offloading some old plain http
applications.

The http ports are listening on 8001, 8002, 8003, etc. I'm using haproxy
1.8.12 to listen on ports 18001, 18002, 18003, etc. using ssl. Everything
works fine, as expected.

I am trying to make stuff a bit more fool-proof for stupid users, and
testing stuff like talking http to https ports, etc. These things are not
supposed to happen, but users sometimes do stupid stuff like that.

When I talk http to a https port, I would expect something like an error
message 'ERROR 400: You are talking http to a https port', or something
like that. This makes it clear to users what they are doing wrong. (Apache
does this.)

However, I get no reply whatsoever. Not even a status code, haproxy just
closes the connection, and curl just says: "* Empty reply from server".
Haproxy logs a nice "SSL handshake failure" error in it's logs, as expected.

I don't know if haproxy was designed to just keep quiet, but I would love
to get a nice error message back. Is this something configurable?

Angelo.


Re: 100% cpu usage 1.9-dev0-48d92ee 2018/07/30, task.?. but keeps working.. (nbthread 1)

2018-08-15 Thread PiBa-NL

Hi List,

Anyone got a idea how to debug this further?
Currently its running at 100% again, any pointers to debug the process 
as its running would be appreciated.


Or should i compile again from current master and 'hope' it doesn't return?

b.t.w. truss output is as follows:
kevent(3,0x0,0,{ },200,{ 0.0 })  = 0 (0x0)
kevent(3,0x0,0,{ },200,{ 0.0 })  = 0 (0x0)
kevent(3,0x0,0,{ },200,{ 0.0 })  = 0 (0x0)
kevent(3,0x0,0,{ },200,{ 0.0 })  = 0 (0x0)
kevent(3,0x0,0,{ },200,{ 0.0 })  = 0 (0x0)
kevent(3,0x0,0,{ },200,{ 0.0 })  = 0 (0x0)
kevent(3,0x0,0,{ },200,{ 0.0 })  = 0 (0x0)

Regards,
PiBa-NL (Pieter)

Op 8-8-2018 om 22:49 schreef PiBa-NL:

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/haprox

cpu-map and definition of LONGBITS

2018-08-15 Thread J. Kendzorra

Hi,

I was looking into steering HAProxy to some underutilized cores on a 
multi processor system where both network interrupts as well as HAProxy 
are supposed to run on a specific numa node; the initial idea was to 
have interrupts handled on cores 0-21 and give HAProxy cores 44-65:

# cat /sys/class/net/em3/device/local_cpulist
0-21,44-65

which could result in a cpu-map setting like this:
cpu-map all 44-65

However, that won't work since this setting is restricted to be no 
higher than LONGBITS which is defined as ((unsigned int)sizeof(long) * 
8). Looking into clues to understand this better I found 
https://marc.info/?l=haproxy&m=144252098801440&w=2 which states:


,--
Let's stay on this version for now. We've been facing a lot of issues in
the past due to over-engineering, so let's wait for users to complain
that 64 is not enough and only then we'll address that and we'll know
why we do it.
`--

This isn't really an issue and I'm not asking to change this; I'd just 
like to understand better the reason why LONGBITS being 64 is the 
maximum for cpu-map. Given that multi processor systems (with multi 
threading enabled) nowadays easily have >64 cores I'd imagine others may 
run into this as well and look for further clues.


Thanks,
J.