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.
On 2019-11-19 17:27, William Lallemand wrote:
On Tue, Nov 19, 2019 at 04:19:26PM +0100, William Lallemand wrote:
> I then add another bind for port 80, which is in use by squid already
> and try to reload HAProxy. It takes some time until it failes:
>
> Nov 19 14:39:21 894a0f616fec haproxy[2978]: [WARNING] 322/143921 (2978)
> : Reexecuting Master process
> ...
> Nov 19 14:39:28 894a0f616fec haproxy[2978]: [ALERT] 322/143922 (2978) :
> Starting frontend somefrontend: cannot bind socket [0.0.0.0:80]
> ...
> Nov 19 14:39:28 894a0f616fec systemd[1]: haproxy.service: Main process
> exited, code=exited, status=1/FAILURE
>
> The reload itself is still running (systemd) and will timeout after
> about 90s. After that, because of the Restart=always, I guess, it ends
> up in a restart loop.
>
> So I would have expected that the master process will fallback to the
> old process and proceed with the old child until the problem has been
> fixed.
>
The patch in attachment fixes a bug where haproxy could reexecute
itself in
waitpid mode with -sf -1.
I'm not sure this is your bug, but if this is the case you should see
haproxy
in waitpid mode, then the master exiting with the usage message in your
logs.
--
Regards,
Christian Ruppert
