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
