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
High Availability Team, which is subscribed to haproxy in Ubuntu.
https://bugs.launchpad.net/bugs/1828496
Title:
service haproxy reload sometimes fails to pick up new TLS certificates
Status in haproxy package in Ubuntu:
Incomplete
Bug description:
I suspect this is the same thing reported on StackOverflow:
"I had this same issue where even after reloading the config, haproxy
would randomly serve old certs. After looking around for many days the
issue was that "reload" operation created a new process without
killing the old one. Confirm this by "ps aux | grep haproxy"."
https://stackoverflow.com/questions/46040504/haproxy-wont-recognize-
new-certificate
In our setup, we automate Let's Encrypt certificate renewals, and a
fresh certificate will trigger a reload of the service. But
occasionally this reload doesn't seem to do anything.
Will update with details next time it happens, and hopefully confirm
the multiple process theory.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/haproxy/+bug/1828496/+subscriptions
_______________________________________________
Mailing list: https://launchpad.net/~ubuntu-ha
Post to : [email protected]
Unsubscribe : https://launchpad.net/~ubuntu-ha
More help : https://help.launchpad.net/ListHelp
