On 2019-11-20 11:05, William Lallemand wrote:
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.

Your patch seems to fix the issue. The master process won't exit anymore. Fallback seems to work during my initial tests. Thanks!

--
Regards,
Christian Ruppert

Reply via email to