Hi, do you have set timeout on keep alive ?
can you share the template you're using for your configuration ? On Thu, Jul 24, 2014 at 3:32 PM, Stefan Majer <stefan.ma...@gmail.com> wrote: > Hi Willy, > > coming back to this old thread. > We still have the problem that from time to time that after doing a > > # service haproxy reload > which actually does > # /usr/sbin/haproxy -f /etc/haproxy/haproxy.cfg -D -p /var/run/haproxy.pid > -sf <pid> > the old process persists and we end up having more than one haproxy process. > The old process will never end (even after days) till we forcefully kill it. > > We issue a haproxy reload every time a configuration change happened which > can happen quite often because, say 50 - 100 times a day. > > To nail this problem down we are finally able to reproduce this behavior > easily ! > > We do the following commands on a recent ubuntu, centos, rhel whatever. We > installed haproxy-1.5.2, and 1.4.25 same effect. > We reload haproxy in parallel by executing: > # service haproxy reload & service haproxy reload & > > repeat this some time (5-10 times) > and you will see: > # ps -ef |grep haproxy > # haproxy 3855 1 0 12:34 ? 00:00:00 /usr/sbin/haproxy -f > /etc/haproxy/haproxy.cfg -p /var/run/haproxy.pid -D -sf 3797 > # haproxy 3950 1 0 12:35 ? 00:00:00 /usr/sbin/haproxy -f > /etc/haproxy/haproxy.cfg -p /var/run/haproxy.pid -D -sf 3932 > > I know it is not recommended to reload a already reloading process, but i > want to make clear that this is a potential source of confusion. > I dont know if it is possible to check if there is already a reload in > progress and return silently ? > > Our actual production haproxy -vv looks like: > HA-Proxy version 1.5.2 2014/07/12 > Copyright 2000-2014 Willy Tarreau <w...@1wt.eu> > > Build options : > TARGET = linux2628 > CPU = generic > CC = gcc > CFLAGS = -O2 -g -fno-strict-aliasing > OPTIONS = USE_LINUX_TPROXY=1 USE_ZLIB=1 USE_REGPARM=1 USE_OPENSSL=1 > USE_PCRE=1 > > Default settings : > maxconn = 2000, bufsize = 16384, maxrewrite = 8192, maxpollevents = 200 > > Encrypted password support via crypt(3): yes > Built with zlib version : 1.2.3 > Compression algorithms supported : identity, deflate, gzip > Built with OpenSSL version : OpenSSL 1.0.1e-fips 11 Feb 2013 > Running on OpenSSL version : OpenSSL 1.0.1e-fips 11 Feb 2013 > OpenSSL library supports TLS extensions : yes > OpenSSL library supports SNI : yes > OpenSSL library supports prefer-server-ciphers : yes > Built with PCRE version : 7.8 2008-09-05 > PCRE library supports JIT : no (USE_PCRE_JIT not set) > Built with transparent proxy support using: IP_TRANSPARENT IPV6_TRANSPARENT > IP_FREEBIND > > 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. > > Hope this clarifies some issues in the list with the same effect. We will > now ensure from the calling side that no parallel reload will be triggered > to prevent this situation. > > Greetings > Stefan Majer > > > On Thu, Jan 30, 2014 at 10:07 AM, Willy Tarreau <w...@1wt.eu> wrote: >> >> Hi Stefan, >> >> On Thu, Jan 30, 2014 at 09:46:12AM +0100, Stefan Majer wrote: >> > Hi Willy, >> > >> > we see the same effect in our environment here as well. >> > We are not sure if this is related to a still open Websocket connection. >> > >> > Do you think that a >> > >> > timeout tunnel 1h # timeout to use with WebSocket and CONNECT >> > >> > in the configuration will help to terminate these processes after the >> > specified timeout. >> >> It's not exactly this. The timeout will ensure that dead or idle >> connections will eventually get killed. But active connections will >> not be killed as long as there is traffic flowing on them. >> >> Haproxy only quits after the last session terminates. So for sure, >> if it is maintained alive because of dead connections, this will >> help. But if there is regular traffic on active connections, it >> will not be enough. >> >> Regards, >> Willy >> > > > > -- > Stefan Majer -- Steven Le Roux Jabber-ID : ste...@jabber.fr 0x39494CCB <ste...@le-roux.info> 2FF7 226B 552E 4709 03F0 6281 72D7 A010 3949 4CCB
