> Le 16 juin 2017 à 18:49, William Lallemand <[email protected]> a écrit : > > > On Fri, Jun 16, 2017 at 05:28:51PM +0200, Emmanuel Hocdet wrote: >> Hi, >> > > Hi Emmanuel, >
Hi William >> 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? > Exactly, use case is to upgrade haproxy from a 1.6/1.7/1.8 compatibility to 1.8 with 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. Okay that great! It’s unusual with a master worker mechanism :) > >> # 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. > It's much simpler than I thought (with mworker). Perhaps keep -x internal to mworker and not expose it to legacy mode could be less confused for users. I will try my test upgrade without -x. > 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 > Thanks William
