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!
** Changed in: haproxy (Ubuntu)
Status: New => Incomplete
--
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
