> Le 16 juin 2017 à 18:49, William Lallemand <will...@haproxy.org> 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


Reply via email to