Hi, I see you are using service(1) to reload haproxy. The service command has been written to manage SysV scripts, but nowadays it prefers calling systemctl when possible. You quoted that:
After looking around for many days the issue was that "reload" operation created a new process without killing the old one. and as haproxy ships with both SysV and systemd init files, this makes me think that service(1) may for some reason fail to call systemctl and ends up reloading haproxy using the SysV script, causing the double process. The first process would in this case keep running, serving the old certificate. However in the Xenial system where I tried to reproduce the issue `service haproxy reload` calls `systemctl reload` as expected. >From /var/log/syslog: May 23 09:39:42 xenial systemd[1]: Reloading HAProxy Load Balancer. May 23 09:39:42 xenial haproxy[26047]: Configuration file is valid May 23 09:39:42 xenial haproxy-systemd-wrapper[25945]: haproxy-systemd-wrapper: re-executing May 23 09:39:42 xenial systemd[1]: Reloaded HAProxy Load Balancer. May 23 09:39:42 xenial haproxy-systemd-wrapper[25945]: haproxy-systemd-wrapper: executing /usr/sbin/haproxy -f /etc/haproxy/haproxy.cfg -p /run/haproxy.pid -Ds -sf 26035 Do you happen to see two haproxy processes when a `service haproxy reload` fails to make haproxy serve the new certificate? Can you still reproduce the issue if you reload haproxy using systemctl instead of service? Can you please attach the tail of /var/log/syslog the next time you encounter the issue? Thank you. -- 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
