Ack/Nack ?
22 сент. 2017 г. 22:44 пользователь "Илья Шипицин"
написал:
> Hello,
>
>
> [contrib/halog/halog.c:1572]: (error) Memory leak: ustat
>
❦ 2 octobre 2017 10:31 +0200, Marcus Ulbrich :
> I am running haproxy 1.7.9-1~bpo9+1 on debian 9.1. And after running a
> while with production data haproxy stops working wiith segmentation
> fault:
>
> haproxy[26291]: segfault at 5562af80e000 ip 7f5985e48149
Hello,
I am running haproxy 1.7.9-1~bpo9+1 on debian 9.1. And after running a
while with production data haproxy stops working wiith segmentation fault:
haproxy[26291]: segfault at 5562af80e000 ip 7f5985e48149 sp
7ffe1d613488 error 4 in libc-2.24
Can you please help or have any
Hi all,
I'm sending you a new set of patches -- fix for warning that appears
when building with 51Degrees release that uses a new Hash Trie algorithm
(release version 3.2.12.12):
* BUILD/MINOR: 51d: fix warning when building with 51Degrees release
version 3.2.12.12
* DOC: 51d: add 51Degrees
Then, remove the chroot directive from HAProxy configuration.
--
Format a program to help the reader understand it.
- The Elements of Programming Style (Kernighan & Plauger)
――― Original Message ―――
From: Marcus Ulbrich
Sent: 2 octobre 2017
❦ 2 octobre 2017 16:05 +0200, Marcus Ulbrich :
> this is linked to /proc/20313/root -> /var/lib/haproxy
>
> and there is dev/log as empty file..
Then, create /var/lib/haproxy/tmp:
mkdir /var/lib/haproxy/tmp
chmod 1777 /var/lib/haproxy/tmp
You should get the
nope... /var/lib/haproxy/tmp/ directory is left empty after crash...
Am 02.10.2017 um 16:09 schrieb Vincent Bernat:
❦ 2 octobre 2017 16:05 +0200, Marcus Ulbrich :
this is linked to /proc/20313/root -> /var/lib/haproxy
and there is dev/log as empty file..
❦ 2 octobre 2017 15:58 +0200, Marcus Ulbrich :
> Yes there is no core dump...
>
> i've ched it and ist was both unlimited...
And "ls -l /proc/xxx/root" is "/" (where xxx is the PID of one of the
HAProxy processes)?
--
What good is an obscenity trial except to
Hello,
Not sure to understand. Is there no core dump or more than one? If none,
did you check in /proc/xxx/status that the limit was correctly applied?
--
Don't just echo the code with comments - make every comment count.
- The Elements of Programming Style (Kernighan & Plauger)
sorry, but it is commented out... :(
Am 02.10.2017 um 16:27 schrieb Vincent Bernat:
Then, remove the chroot directive from HAProxy configuration.
❦ 2 octobre 2017 16:29 +0200, Marcus Ulbrich :
> sorry, but it is commented out... :(
Humm, I don't see how HAProxy would chroot itself without this
directive. Let's try to get the core inside the chroot.
Could you confirm the output of:
sysctl
okay...
$# sysctl kernel.core_pattern
kernel.core_pattern = /tmp/core.%e.%p.%h.%t
$# ls -ld /var/lib/haproxy/tmp
drwxrwxrwt 2 root root 4096 Okt 2 16:11 /var/lib/haproxy/tmp
Hello Vincent,
thanks for your reply. I have done what you said... but there ist nore
core file dumped in /tmp/.
running gdb console it only says "[Inferior 1 (process 719) exited
normally]" when the segfault error occours and haproxy restarts. bt and
bt full results in "No stack."
Can
Well, I have no idea why you don't get those core files. It's also quite
odd that you get chrooted without the chroot directive. Maybre 'rgrep
chroot /etc' to check if there is anything fishy. Is there anything
special in your environment? Running in a container with memory limits
maybe?
To be
❦ 2 octobre 2017 17:06 +0200, Marcus Ulbrich :
> I even get no core dump with the python oneliner either with chroot
> nor without...
So, kernel.core_pattern seems to be problematic (unrelated, but my
python one-liner wasn't totally correct either). Try again
Hi,
The attached patches add experimental support for 0-RTT with OpenSSL 1.1.1
They are based on Emmanuel's previous patches, so I'm submitting them again,
updated to reflect the changes in OpenSSL API, and with a few fixes.
To allow the use of early data, one has to explicitely add "allow-0rtt"
okay, here the outputs:
rgrep chroot /etc:
/etc/rsyslog.d/49-haproxy.conf:# Create an additional socket in
haproxy's chroot in order to allow logging via
/etc/rsyslog.d/49-haproxy.conf:# /dev/log to chroot'ed HAProxy processes
The machine is only a virtualbox machine... but this was no a
Could you get another one with libssl1.1-dbgsym installed? But just with
that, maybe other people could infer what's wrong.
--
Make sure comments and code agree.
- The Elements of Programming Style (Kernighan & Plauger)
――― Original Message ―――
From: Marcus Ulbrich
yes... core of python script is there than... but i can't get one of
haproxy segfault :-/
❦ 2 octobre 2017 18:38 +0200, Marcus Ulbrich :
> yes... core of python script is there than... but i can't get one of
> haproxy segfault :-/
Not even in /var/lib/haproxy then?
If it works with the Python script, try set kernel.core_pattern to just
"/tmp/core".
no chance... error or killing haproxy there is no core file there...
wether in /var/lib, nor in /tmp
I am frustrated...
Hi Igor,
On Tue, Oct 03, 2017 at 12:06:05AM +0800, Igor Pav wrote:
> It's excited, does server line(client side) support 0-rtt?
>
Unfortunately, it does not yet. I'm investigating adding it.
Regards,
Olivier
> On Mon, Oct 2, 2017 at 11:18 PM, Olivier Houchard
>
How many haproxy process do you have? Can you reduce nbprocs to 1 if you set it
to another value? In this case, attach directly to haproxy with gdb -p pid,
type continue to unblock it and wait for the segfault. Then bt full.
On October 2, 2017 6:59:47 PM GMT+02:00, Marcus Ulbrich
you can try to attach like that
https://stackoverflow.com/questions/2152582/start-gdb-using-a-pid
(I still think, that core dump is better if possible)
2017-10-02 21:59 GMT+05:00 Marcus Ulbrich :
> no chance... error or killing haproxy there is no core file
Okay... I've got a core dump... Thanks a lot!!!
But what this means?
Program received signal SIGSEGV, Segmentation fault.
__memmove_sse2_unaligned_erms () at
../sysdeps/x86_64/multiarch/../multiarch/memmove-vec-unaligned-erms.S:
25 matches
Mail list logo