Comment 11 for bug 1828496

Hi Barry,

I tried again to reproduce the issue on Xenial, but without success. I tested by 'reloading' the service several times, and in all the reloads the PIDs of the haproxy processes did change, as expected given the version of haproxy currently in Xenial.

In order to investigate the issue we need some more details. To begin with:

1) How often do you experience the problem? Is this a rare, difficult to reproduce issue, or something you can easily reproduce? I'm not asking to evaluate the severity of the issue, but to be able to test in a meaningful way.

2) When you hit the problem, can you check if the PIDs of the haproxy processes change after reloading the service?

I imagine a scenario where you have several auto-renewing certificates with a hook/script reloading haproxy on cert renewal, and from time to time you find out that an old certificate is getting served, even if it has been renewed and the haproxy service reloaded. It this case it would be nice to log a few things before and after the reload (e.g. verify that the new certs are actually in place, `ps fauxww`, `systemctl status`, haproxy.log, ...), sleeping for a few seconds after the reload command is issued, to give time for the daemons to restart.

Once again after providing additional information please set the bug status back to New. Thanks!