Hi Steven,
the actual config is:
global
log /dev/log local0
log /dev/log local1 notice
chroot /var/lib/haproxy
stats socket /run/haproxy/admin.sock mode 660 level admin
stats timeout 30s
user haproxy
group haproxy
daemon
# Default SSL material locations
ca-base /etc/ssl/certs
crt-base /etc/ssl/private
# Default ciphers to use on SSL-enabled listening sockets.
# For more information, see ciphers(1SSL).
ssl-default-bind-ciphers
kEECDH+aRSA+AES:kRSA+AES:+AES256:RC4-SHA:!kEDH:!LOW:!EXP:!MD5:!aNULL:!eNULL
defaults
log global
mode http
option httplog
option dontlognull
timeout connect 5000
timeout client 50000
timeout server 50000
errorfile 400 /etc/haproxy/errors/400.http
errorfile 403 /etc/haproxy/errors/403.http
errorfile 408 /etc/haproxy/errors/408.http
errorfile 500 /etc/haproxy/errors/500.http
errorfile 502 /etc/haproxy/errors/502.http
errorfile 503 /etc/haproxy/errors/503.http
errorfile 504 /etc/haproxy/errors/504.http
This is a totally idle server which actually does not loadbalancing at all.
Hope this helps
Stefan Majer
On Thu, Jul 24, 2014 at 4:06 PM, Steven Le Roux <[email protected]> wrote:
> 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 <[email protected]>
> 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 <[email protected]>
> >
> > 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 <[email protected]> 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 : [email protected]
> 0x39494CCB <[email protected]>
> 2FF7 226B 552E 4709 03F0 6281 72D7 A010 3949 4CCB
>
--
Stefan Majer
