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
