Something similar came up today on a Trusty instance, the WARNING lines
are possibly relevant here. To be clear, no certificates were involved
in this case, but I did catch the old processes still running after a
reload:
ubuntu@foo:~$ ps auxfwwww | grep haproxy
ubuntu 10790 0.0 0.0 10480 932 pts/2 S+ 07:20 0:00
\_ grep --color=auto haproxy
haproxy 15581 0.0 0.0 21424 2048 ? Ss May23 1:36
/usr/sbin/haproxy -f /etc/haproxy/haproxy.cfg -p /var/run/haproxy.pid -D -sf
15502
ubuntu@foo:~$ sudo service haproxy reload
* Reloading haproxy haproxy
[WARNING] 143/072015
(10813) : config : 'option httplog' not usable with frontend 'foo-lb-2-80'
(needs 'mode http'). Falling back to 'option tcplog'.
[WARNING] 143/072015 (10815) : config : 'option httplog' not usable with
frontend 'foo-lb-2-80' (needs 'mode http'). Falling back to 'option tcplog'.
[ OK ]
ubuntu@foo:~$ ps auxfwwww | grep haproxy
ubuntu 10845 0.0 0.0 10480 932 pts/2 S+ 07:20 0:00
\_ grep --color=auto haproxy
haproxy 15581 0.0 0.0 21424 2048 ? Ss May23 1:36
/usr/sbin/haproxy -f /etc/haproxy/haproxy.cfg -p /var/run/haproxy.pid -D -sf
15502
haproxy 10816 0.0 0.0 21016 1536 ? Ss 07:20 0:00
/usr/sbin/haproxy -f /etc/haproxy/haproxy.cfg -p /var/run/haproxy.pid -D -sf
15581
ubuntu@juju-prodstack-ols-assertions-sign-machine-14:~$
In this case though, neither a 'service haproxy restart' nor a
stop+start would kill the old process, I had to send it a TERM signal in
the end.
I understand that Trusty is no longer supported outside of ESM - if this
isn't helpful, I'll delete and update if/when I can reproduce on Xenial
or later.
--
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