On Wed, Nov 20, 2019 at 10:19:20AM +0100, Christian Ruppert wrote:
> Hi William,
> 
> thanks for the patch. I'll test it later today.  What I actually wanted to
> achieve is: https://cbonte.github.io/haproxy-dconv/2.0/management.html#4 Then
> HAProxy tries to bind to all listening ports. If some fatal errors happen
> (eg: address not present on the system, permission denied), the process quits
> with an error. If a socket binding fails because a port is already in use,
> then the process will first send a SIGTTOU signal to all the pids specified
> in the "-st" or "-sf" pid list. This is what is called the "pause" signal. It
> instructs all existing haproxy processes to temporarily stop listening to
> their ports so that the new process can try to bind again. During this time,
> the old process continues to process existing connections. If the binding
> still fails (because for example a port is shared with another daemon), then
> the new process sends a SIGTTIN signal to the old processes to instruct them
> to resume operations just as if nothing happened. The old processes will then
> restart listening to the ports and continue to accept connections. Not that
> this mechanism is system
> 
> In my test case though it failed to do so.

Well, it only works with HAProxy processes, not with other processes. There is
no mechanism to ask a process which is neither an haproxy process nor a process
which use SO_REUSEPORT.

With HAProxy processes it will bind with SO_REUSEPORT, and will only use the
SIGTTOU/SIGTTIN signals if it fails to do so.

This part of the documentation is for HAProxy without master-worker mode
in master-worker mode, once the master is launched successfully it is never
supposed to quit upon a reload (kill -USR2).

During a reload in master-worker mode, the master will do a -sf <pids of old 
workers>. 
If the reload failed for any reason (bad configuration, unable to bind etc.),
the behavior is to keep the previous workers. It only tries to kill the workers
if the reload succeed. So this is the default behavior.

-- 
William Lallemand

Reply via email to