On Fri, Jun 16, 2017 at 05:28:51PM +0200, Emmanuel Hocdet wrote: > Hi, >
Hi Emmanuel, > i try to play with that, but i’m a little confused with the behaviour. > > In my test, i use alternatly haproxy upgrade and worker reload (via USR2) > > start with upgrade: > # /usr/sbin/haproxy -f /var/lib/haproxy/ssl/ssl.cfg -p > /var/run/haproxy_ssl.pid -D -W -n 131072 -L ssl_1 -x > /var/run/haproxy/ssl.sock1 -x /var/run/haproxy/ssl.sock2 -sf `cat > /var/run/haproxy_ssl.pid` > [ALERT] 166/165607 (13616) : Current worker 13618 left with exit code 0 > [ALERT] 166/165607 (13616) : Current worker 13617 left with exit code 0 > [WARNING] 166/165607 (13616) : All workers are left. Leaving... (0) I'm not sure of what you are trying to do, do you try to upgrade an HAProxy which is not using the master worker mode to a master worker? In master worker mode the reload is meant to be done only with the USR2 signal, the binary will be reloaded upon this signal so you don't have to start another process to upgrade the binary. > # ps auxwww |grep ssl > > root 13635 0.0 0.0 79132 776 pts/0 S 16:59 0:00 > /usr/sbin/haproxy -f /var/lib/haproxy/ssl/ssl.cfg -p /var/run/haproxy_ssl.pid > -D -W -n 131072 -L ssl_1 -x /var/run/haproxy/ssl.sock1 -x > /var/run/haproxy/ssl.sock2 -sf 13617 13618 > haproxy 13636 0.0 0.0 79132 940 ? Ss 16:59 0:00 > /usr/sbin/haproxy -f /var/lib/haproxy/ssl/ssl.cfg -p /var/run/haproxy_ssl.pid > -D -W -n 131072 -L ssl_1 -x /var/run/haproxy/ssl.sock1 -x > /var/run/haproxy/ssl.sock2 -sf 13617 13618 > haproxy 13637 0.0 0.0 79132 940 ? Ss 16:59 0:00 > /usr/sbin/haproxy -f /var/lib/haproxy/ssl/ssl.cfg -p /var/run/haproxy_ssl.pid > -D -W -n 131072 -L ssl_1 -x /var/run/haproxy/ssl.sock1 -x > /var/run/haproxy/ssl.sock2 -sf 13617 13618 > > seems ok, try to reload via USR2 on master. > first note: the pid of master is not log in /var/run (only childrens) and i > don’t see any option to set it in a file (to use it in a script) > That's right, it was one of the probable evolution. I will probably log only the pid of the master in future patches. > # kill -USR2 13635 > # [WARNING] 166/165947 (13635) : Reexecuting Master process > [WARNING] 166/170818 (13635) : Former worker 13636 left with exit code 0 > [WARNING] 166/170818 (13635) : Former worker 13637 left with exit code 0 > Looks like a normal behavior. > # ps auxwww |grep ssl > root 13635 0.0 2.1 79132 44424 pts/0 S 16:59 0:00 > /usr/sbin/haproxy -f /var/lib/haproxy/ssl/ssl.cfg -p /var/run/haproxy_ssl.pid > -D -W -n 131072 -L ssl_1 -x /var/run/haproxy/ssl.sock2 -x > /var/run/haproxy/ssl.sock2 -sf 13636 13637 13617 13618 > haproxy 13652 0.0 0.0 79132 1188 ? Ss 17:08 0:00 > /usr/sbin/haproxy -f /var/lib/haproxy/ssl/ssl.cfg -p /var/run/haproxy_ssl.pid > -D -W -n 131072 -L ssl_1 -x /var/run/haproxy/ssl.sock2 -x > /var/run/haproxy/ssl.sock2 -sf 13636 13637 13617 13618 > haproxy 13653 0.0 0.0 79132 1176 ? Ss 17:08 0:00 > /usr/sbin/haproxy -f /var/lib/haproxy/ssl/ssl.cfg -p /var/run/haproxy_ssl.pid > -D -W -n 131072 -L ssl_1 -x /var/run/haproxy/ssl.sock2 -x > /var/run/haproxy/ssl.sock2 -sf 13636 13637 13617 13618 > root 13655 0.0 0.0 11124 696 pts/0 S+ 17:08 0:00 grep ssl > > I now see -x /var/run/haproxy/ssl.sock2 twice (sock1 is lost) and -sf have 4 > pids instead of 2. > Well, that's a bug, the code of the mworker doesn't manage several -x. However you don't need to use several unix sockets, the fd of all listeners are exposed in any process using the "expose-fd listeners" keyword, even if the listeners are bind on another process. The master worker reexec the process adding a -x with what it found in the configuration, you don't have to start it with -x at startup. Regarding the PID, I think you have this behavior because you started the daemon mode with -sf. > one last: > # haproxy -x > Segmentation fault I'll fix that. > > ++ > Manu > Thanks for the tests! -- William Lallemand
