On 2019-11-20 11:05, William Lallemand wrote:
On Wed, Nov 20, 2019 at 10:19:20AM +0100, Christian Ruppert wrote:
thanks for the patch. I'll test it later today. What I actually
HAProxy tries to bind to all listening ports. If some fatal errors
(eg: address not present on the system, permission denied), the
with an error. If a socket binding fails because a port is already in
then the process will first send a SIGTTOU signal to all the pids
in the "-st" or "-sf" pid list. This is what is called the "pause"
instructs all existing haproxy processes to temporarily stop listening
their ports so that the new process can try to bind again. During this
the old process continues to process existing connections. If the
still fails (because for example a port is shared with another
the new process sends a SIGTTIN signal to the old processes to
to resume operations just as if nothing happened. The old processes
restart listening to the ports and continue to accept connections. Not
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.
no mechanism to ask a process which is neither an haproxy process nor a
which use SO_REUSEPORT.
With HAProxy processes it will bind with SO_REUSEPORT, and will only
SIGTTOU/SIGTTIN signals if it fails to do so.
This part of the documentation is for HAProxy without master-worker
in master-worker mode, once the master is launched successfully it is
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
the behavior is to keep the previous workers. It only tries to kill the
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!