Hi William,

thanks for the patch. I'll test it later today.
What I actually wanted to achieve is:
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 []
> ...
> 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.

Christian Ruppert

Reply via email to