Never mind, here it is on Xenial: https://pastebin.ubuntu.com/p/3zbQdnTBtF/
There's nothing relevant to haproxy in syslog, but here's the relevant lines from /var/log/haproxy.log: https://pastebin.ubuntu.com/p/HJT3WRc8Dw/ While the proxy processes apparently did stop, the pid 2215 process did not. Running 'systemctl restart haproxy.service' afterwards killed both processes, and started a single fresh one with a new pid, which I think is correct behaviour. So this does indeed seem likely to be down to using 'service' here. -- 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
