Comment 8 for bug 1828496

Hi Barry,

Glad that you have a workaround, but I don't think we nailed the problem. You are now using the 'restart' action, which is stronger than a 'reload', and I bet that a 'service haproxy restart' would have worked too. The 'restart' action fully stops and then starts the service, while 'reload' sends the USR2 signal to haproxy. The systemd unit file defining the reload action comes from upstream.

This is what I found out. As of the version of haproxy in Xenial (1.6.x) the only two things mentioning the usage of SIGUSR2 to reload the service are the upstream changelog:

  - MINOR: systemd wrapper: re-execute on SIGUSR2

and the systemd unit file actually using it.

With haproxy 1.8 upstream announced [1] a much improved management of multiple haproxy processes with the newly introduced master-worker mode, finally documenting [2] SIGUSR2 as the correct the way to make haproxy reload:

    In master-worker mode, it is not needed to start a new haproxy
    process in order to reload the configuration. The master process
    reacts to the SIGUSR2 signal by reexecuting itself with the -sf
    parameter followed by the PIDs of the workers. The master will
    then parse the configuration file and fork new workers.

My take is that in haproxy 1.6 SIGUSR2 isn't working well as a way to reload the haproxy configuration file, a full 'restart' may be necessary.

It is still not clear to me why I *do* see the PIDs of the haproxy processes changing with a 'service haproxy reload', while Andreas doesn't.

[1] https://www.haproxy.com/blog/whats-new-haproxy-1-8/
[2] https://cbonte.github.io/haproxy-dconv/1.8/management.html