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

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1828496

Title:
  service haproxy reload sometimes fails to pick up new TLS certificates

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/haproxy/+bug/1828496/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Reply via email to